Management of electronic offers by an offer distributor

ABSTRACT

According to an embodiment, a data processing system for assisting an offer distributor to manage electronic offers comprises: a first logic module adapted to receive two electronic offers from different offer providers, a first set of offer data relating to the first offer, and a second set of offer data relating to the second offer; and a second logic module adapted to select one of the two offers for distribution to a consumer, the selection being based on the first set of offer data and the second set of offer data. In an embodiment, the selected offer is distributed in response to a request for a receipt. In an embodiment, the selected offer is included in a transaction receipt transmitted to a customer data processing system. In an embodiment, the selection is made in response to a set of events, or is further based on a set of events.

This application claims the benefit under 35 U.S.C. §119(e) ofProvisional Application 61/745,566, filed Dec. 22, 2012, and ofProvisional Application 61/788,009, filed Mar. 15, 2013, the entirecontents of each of which applications are hereby incorporated byreference for all purposes as if fully set forth herein.

This application is related to: “Checkout-Based Distributed Of DigitalPromotions” by Steven R. Boal, U.S. application Ser. No. 13/233,557,filed Sep. 15, 2011; U.S. application Ser. No. 13/831,716, filed Mar.15, 2013; “Checkout-Based Distributed Of Digital Promotions” by StevenR. Boal, U.S. application Ser. No. 13/244,817, filed Sep. 26, 2011;“Check-Out Based Distribution And Redemption Of Digital Promotions” bySteven R. Boal, U.S. application Ser. No. 13/332,317, filed Dec. 20,2011; “Automatic Recommendation of Digital Offers to an Offer Providerbased on Historical Transaction Data” by Steven R. Boal, Attorney DocketNo. 60202-0244, filed this same day herewith; “Selection of DigitalOffers based on Current and Historical Transaction Data” by Steven R.Boal, Attorney Docket No. 60202-0245, filed this same day herewith;“Automatic Recommendation of Electronic Offers to an Offer Providerbased on Historical Transaction Data and Offer Data” by Steven R. Boal,Attorney Docket No. 60202-0246, filed this same day herewith;“Integrated Management of Targeted and Recommended Electronic Offers” bySteven R. Boal, Attorney Docket No. 60202-0247, filed this same dayherewith; “Consumer Identity Resolution based on Transaction Data” bySteven R. Boal, Attorney Docket No. 60202-0248, filed this same dayherewith; “Systems and Methods for Recommendation of Electronic Offers”by Steven R. Boal, Attorney Docket No. 60202-0285, filed this same dayherewith; “Recommendation of Electronic Offers based on UniversalScoring Functions” by Steven R. Boal, Attorney Docket No. 60202-0286,filed this same day herewith; “Identity Resolution for Consumers withShared Credentials” by Steven R. Boal, Attorney Docket No. 60202-0287,filed this same day herewith; “Generation and Management of DynamicElectronic Offers” by Steven R. Boal, Attorney Docket No. 60202-0288,filed this same day herewith; and “Management of Electronic Offers by AnOffer Distributor” by Steven R. Boal, Attorney Docket No. 60202-0289,filed this same day herewith. The entire contents of each of the abovelisted applications are hereby incorporated by reference for allpurposes as if fully set forth herein.

TECHNICAL FIELD

Embodiments relate generally to the generation, processing, storage,management, usage, distribution and/or delivery of digital offers,including digital coupons and other digital promotional vehicles.

BACKGROUND

Approaches described in this Background section may include approachesthat could be pursued, but not necessarily approaches that have beenpreviously conceived or pursued. Therefore, unless otherwise indicated,it should not be assumed that any of the approaches described in thissection qualify as prior art merely by virtue of their inclusion in thissection.

Targeted marketing techniques assist a variety of entities, such asproduct manufacturers, service providers, and retailers, in efficientlypersuading consumers to purchase certain products and service. Amarketing entity may include, without limitation, product manufacturers,service providers, retailers, third-party marketing firms acting onbehalf of another entity, non-profit organizations, and so forth. Themarketing entity may identify characteristics of people to which theentity wishes to “market” a product or service. For example, an entitythat sells product X may determine that it wants to market to personsthat have purchased a complimentary product Y within a timeframe of Z.Of course, one problem with targeted marketing is that it is sometimesdifficult to ascertain exactly what characteristics to target.

Once targeted characteristics have been identified, the entity may thenattempt to “market” to persons who have those characteristics.Unfortunately, it is also generally difficult to ascertain whether agiven person actually has the targeted characteristics and/or how toactually reach specific persons that have those specificcharacteristics. For example, a particular retailer may have no ideathat a potential consumer recently purchased product Y from anotherstore, and thus be unable to specifically target marketing for Product Xto that potential consumer. Large-scale targeted marketing is thereforetypically difficult to achieve with a high degree of efficiency. Rather,a marketing entity is typically limited to less efficient targetingtechniques, such as targeting specific zip codes or web sites, thusresulting in the marketing entity wasting marketing resources on manypersons who do not have the targeted characteristics.

One common marketing technique involves incentivizing costumer behaviorthrough targeted promotional offers. An “offer” may be construed to be apromise by an offer provider, which may be any entity engaged intargeted marketing, to provide a consumer with a benefit under a certainset of implicit or explicit conditions known as terms. Example benefitsinclude, without limitation, a monetary gift, a discount applied to thepurchase of one or more products or services, free products and/orservices, access to additional offers, and so forth. Example terms mayinclude any one or more of, without limitation, actions that theconsumer must perform, a specific set of item(s) that must be purchasedby the consumer, a specific amount of money that must be spent by theconsumer, a timeframe during which the offer is valid, and so forth. Acustomer benefit of an offer is realized during a process sometimescalled “redemption,” which typically takes place during a transactionbetween the consumer and a retailer. When the consumer wishes to engagein a transaction the retailer determines whether the conditions of theoffer have been met. If so, the retailer, which may be any merchant orother entity that sells products or services, provides the benefit tothe consumer on behalf of the offer provider.

In some embodiments, the retailer is in fact the offer provider. Inother embodiments, the retailer may then seek compensation for providingthe benefit from the offer provider by means of a process known asclearing. During the clearing process, the retailer provides evidence toa third-party clearinghouse, or directly to the offer provider, that theretailer provided the benefit. Assuming the evidence is sufficient, thethird-party clearinghouse, or offer provider, provides compensation tothe retailer. In embodiments involving a third-party clearinghouse, theoffer provider may provide the third-party clearinghouse with funds inadvance. The offer provider also sends to the third-party clearinghousefunds from which the compensation is provided, or reimburses thethird-party clearinghouse for providing the compensation.

A frequent implicit or explicit term of an offer is that the retailermust be presented with a specific coupon during a transaction. Ingeneral, a coupon is a certificate, document, or other physical orelectronic construct that entitles a consumer to accept an offerdescribed or referenced by the coupon, thereby realizing the benefit ofthe offer. A coupon sometimes takes a “hard copy” form, such as a papercertificate, with printed images and/or text describing terms of theoffer. The process of the consumer accepting an offer by presenting,referencing, or otherwise providing a coupon while purchasing,contracting, or otherwise transacting with another party involves“redeeming” the coupon. For example, a consumer may redeem a hard copyof a coupon by handing the copy to a clerk during a purchase at a retailstore. The clerk may then provide the consumer with the subject of theoffer, such as a discounted price, item, service or gift.

One technique for distributing coupons is to include printed couponswith newspapers, magazines, or other items that are distributed toconsumers. One example of an item with which coupons are distributed isa printed receipt. For example, some retailers print receipts at a pointof sale on register paper on which coupons have been pre-printed. Asanother example, some retailers print coupon(s) on a receipt at the timeof the transaction for which the receipt is printed, thereby allowingthe retailers to dynamically select which coupon(s) appear on thereceipt based on the product(s) that were purchased during thetransaction.

Recent distribution techniques now provide consumers with opportunitiesto print their own coupons. For example, a number of websites providesearch engines or catalogs with which consumers may locate offers andthen print coupons for the offers they find. The printed coupons may beused in the same manner as any other coupon.

Other recent distribution techniques involve creating digital coupons.One such technique involves creating unique digital coupons that aresaved to an account associated with the consumer, such as a storeloyalty account. The consumer may redeem such digital coupons duringonline or physical transactions by presenting an account identifier,such as a store loyalty card or an oral identification of the consumer'stelephone number, for the associated account. Since many consumeraccounts are tied to card-based identifiers, such as store loyalty cardsor credit cards, the process of storing a digital coupon identifier toan account may also be referred to as saving a coupon to a card. Someexamples of such techniques are described in U.S. application Ser. No.12/878,231, filed Sep. 9, 2010, the entire contents of which are herebyincorporated by reference for all purposes as if fully set forth herein.

Another digital coupon-based technique involves creating unique digitalcoupons that may be stored on a computing device. The digital couponsmay be transmitted from the computing device to a point-of-sale during atransaction using any of a variety of mechanisms. For example,information about the digital coupon may be uploaded to thepoint-of-sale during an online transaction involving the computingdevice. As another example, information about the digital coupon may betransmitted wirelessly from a smartphone to a receiving componentcoupled to a checkout register during a transaction at abrick-and-mortar store.

Considering the current state of the industry and market for digitaloffers (including digital coupons and other digital promotional discountvehicles), there is a need for improved systems, methods and technologyplatforms for generating, processing, storing, managing and deliveringdigital offers, for enhancing and customizing the digital offerexperience of consumers in general, for increasing the value andbenefits derived by consumers from digital offers, for improving theability of offer providers, offer distributors and retailers tocustomize digital offer selection, delivery, utilization, management,monetization and redemption analysis, and for otherwise increasing theefficiency and financial return of the digital offer industry andmarket.

SUMMARY OF THE INVENTION

The appended claims may serve to summarize the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 illustrates an email comprising an electronic receipt with offerinformation that has been provided to an electronic address of aconsumer, in accordance with an embodiment;

FIG. 2 depicts an example graphical user interface with which a consumermay view and select offers, in accordance with an embodiment;

FIG. 3 illustrates a method flow for conducting a transaction in whichan electronic receipt may be provided, in accordance with an embodiment;

FIG. 4 illustrates a method flow for electronically providing offerinformation in association with a receipt for a transaction conducted ata brick-or-mortar store, in accordance with an embodiment;

FIG. 5 illustrates an example system in which the techniques describedherein may be practiced, in accordance with an embodiment;

FIG. 6 and FIG. 7 illustrate flows for providing an electronic receiptwith offer information, in accordance with embodiments;

FIG. 8 illustrates a computer configured to implement certainembodiments, in accordance with an embodiment;

FIG. 9 is block diagram of a data processing system upon whichembodiments of the invention may be implemented, in accordance with anembodiment;

FIG. 10 illustrates a retailer-centric flow for using a single consumeridentifier to locate digital offers for redemption in a transaction, andto identify an electronic address at which to provide a digital receipt,in accordance with an embodiment;

FIG. 11 illustrates a distributor-centric flow for using a singleconsumer identifier to locate digital offers for redemption in atransaction, and to identify an electronic address at which to provide adigital receipt, in accordance with an embodiment;

FIG. 12 illustrates a flow for providing offers based on transactionaldata gathered from multiple different retailers, in accordance with anembodiment;

FIG. 13A illustrates a system for providing offers based ontransactional data gathered from multiple different retailers, inaccordance with an embodiment;

FIG. 13B is a different view of system for providing offers based ontransactional data gathered from multiple different retailers, inaccordance with an embodiment;

FIG. 14 illustrates a system for providing offers based on transactionaldata gathered by a payment system from multiple different retailers, inaccordance with an embodiment;

FIG. 15 illustrates an example system for defining offers, in accordancewith an embodiment;

FIG. 16 illustrates an example system for distributing targeted offers,in accordance with an embodiment;

FIG. 17 illustrates an example system for recommending offers, inaccordance with an embodiment;

FIG. 18 is a flow illustrating a method of providing offers at aconsumer-operated device, in accordance with an embodiment;

FIG. 19 illustrates another example process flow for offer redemptionwith a retailer, in accordance with an embodiment;

FIG. 20 illustrates an example process flow for offer redemption by apayment provider, in accordance with an embodiment;

FIG. 21 illustrates an example flow of storing and accessing consumerrecords for differentiating between consumers by resolving credentialsto consumer entities, in accordance with an embodiment;

FIG. 22 illustrates an example flow for providing offers at endpointsoperated by retailers, in accordance with an embodiment;

FIG. 23 illustrates a flow for targeting offers to specific consumerentities, in accordance with an embodiment;

FIG. 24 illustrates an example flow for recommending offers, inaccordance with an embodiment;

FIG. 25 depicts an example flow for generating a recommendation based ona universal scoring mechanism, in accordance with an embodiment;

FIG. 26 depicts an example flow for calculating a universal score, inaccordance with an embodiment;

FIG. 27 illustrates an example flow for integrating offer recommendationand offer targeting within a single offer distribution system, inaccordance with an embodiment;

FIG. 28 illustrates a flow for proposing offers, terms, targets, and/orcampaign parameters to a provider, in accordance with an embodiment;

FIG. 29 illustrates a flow for utilizing dynamic offers, in accordancewith an embodiment;

FIG. 30 illustrates a flow for differentiating between consumers whoprovide ambiguous credentials, in accordance with an embodiment;

FIG. 31 illustrates a system for integrating offer recommendations andtargeted offers, in accordance with an embodiment;

FIG. 32 illustrates a process flow for an example recommendation engine,in accordance with an embodiment;

FIG. 33 illustrates another example recommendation engine based on sixdifferent scoring functions, each of which is specific to a certaincategory of signals, in accordance with an embodiment;

FIG. 34 illustrates a system for distinguishing between consumers toresolve consumers to unique consumer identities that span records frommultiple sources, in accordance with an embodiment;

FIG. 35 illustrates an example webpage comprising an electronic receiptwith embedded offer information, in accordance with an embodiment;

FIG. 36 illustrates a webpage comprising an interactive list of aconsumer's receipts, in accordance with an embodiment.

DESCRIPTION OF EXAMPLE EMBODIMENTS

In the following description, for the purposes of explanation, numerousdetails are set forth in order to provide a thorough understanding ofvarious embodiments of the present invention. It will be apparent,however, that various embodiments of the present invention may bepracticed without these specific details. In other instances, well-knownstructures and devices are shown in block diagram form in order to avoidunnecessarily obscuring the present invention.

1.0. General Overview

The following describes systems and methods for addressing needs such asdescribed above, among other needs, by integrating and processingtransaction data from a plurality of retailers in connection withdigital offers, including digital coupons and other digital promotionaldiscount vehicles, in accordance with various embodiments.

According to an embodiment, a data processing system for assisting anoffer distributor to manage electronic offers comprises: a first logicmodule adapted to receive at least two electronic offers from differentoffer providers, a first set of offer data relating to the first offer,and a second set of offer data relating to the second offer; and asecond logic module adapted to select one of the two offers fordistribution to a consumer, the selection being based on the first setof offer data and the second set of offer data.

In an embodiment, the selected offer is distributed in response to arequest for a receipt. In an embodiment, the selected offer is includedin a transaction receipt transmitted to a customer data processingsystem. In an embodiment, the customer data processing system is atleast one of: a desktop computer, laptop computer, netbook, electronicnotebook, ultra mobile personal computer (UMPC), electronic tablet,client computing device, client terminal, client console, mobiletelephone, smartphone, wearable computer, head-mounted computer, orpersonal digital assistant. In an embodiment, the selection of the offeris further based on an incentive provided by one of the offer providersto the offer distributor.

In an embodiment, one of the offer providers is an offer distributor,and the selection of the offer is further based on an incentive providedby the offer distributor. In an embodiment, at least one of the firstset of offer data and the second set of offer data includes one or moreof: an offer provider identity, a historical or projected impact of anoffer on sales of an item, a historical or projected offer redemptionrate, a historical or projected profit per offer impression, ahistorical or projected profit margin, a historical or projected offervolume, a historical or projected offer yield, a historical trend inoffers made available by an offer provider, a historical or projectedprofit margin for the offer distributor, a historical or projectedprofit margin for an offer provider, a historical or projected impact ofan offer on other offers, or a historical or projected impact of anoffer on consumer behavior.

In an embodiment, the selection is made in response to a set of events,or is further based on a set of events. In an embodiment, the set ofevents includes at least one of: an electronic transaction, a webrequest, an offer redemption, an offer activation, a visit by a consumerto a specific location, use of a smartphone application, use of anelectronic shopping list, an ATM withdrawal, reserving, booking orembarking on an airline flight, the filling or issuance of a medicalprescription, a visit to a manufacturer's website, adding an item to anonline shopping cart, viewing or activating an offer on the offerdistributor's website, viewing a digital receipt, an electronic messageto a manufacturer, or an electronic message that references a productfrom a manufacturer. In an embodiment, the set of events is obtained atleast in part from a web log, an electronic transaction log, or acollection of normalized events corresponding to a plurality oftransactions and web requests. In an embodiment, at least two events aregenerated in response to messages from different endpoints, includingone or more of a retailer terminal, retailer website, consumer device,social networking server, or payment server. In an embodiment, at leasta subset of the events is aggregated in a data store. In an embodiment,an event is correlated to a historical transaction record associatedwith a consumer based on determination of a probability that the eventreflects activity by that consumer.

In an embodiment, the selection is further based on a set of targetcontexts. In an embodiment, the set of target contexts includes at leastone: demographic information about a consumer on whose behalf a requestwas likely made, a location associated with a request, information abouta retailer associated with a request, transactional or offer-relatedactions taken by a consumer, one or more items in an electronic shoppinglist or shopping cart associated with a consumer, or a time or day whena request was made. In an embodiment, at least one target context isautomatically defined based on a set of historical transaction records.

In an embodiment, the selection is further based on a set of historicaltransaction records. In an embodiment, the set of historical transactionrecords include at least one of: a universal product code, a quantity ofproduct purchased, a number of items purchased, a transaction amount, atleast a portion of a credit card number used, a payment identifier used,a secure payment hash key, a data processing system or facility, time,date, one or more offers activated or redeemed, a customer name, a phonenumber, a pin number, a password, a code, a loyalty card number, RFIDdata, a device identifier, one or more items that were purchased in aprevious, concurrent or subsequent transaction, or a transaction number.

In an embodiment, the selection is further based on a set of contextualtransaction data. In an embodiment, the contextual transaction dataincludes at least one of: information regarding a universal productcode, a quantity of product purchased, a number of items purchased, atransaction amount, at least a portion of a credit card number used, apayment identifier used, a secure payment hash key, a data processingsystem or facility, time, date, one or more offers activated orredeemed, customer name, phone number, pin number, password, code,loyalty card number, RFID data, a device identifier, one or more itemsthat were purchased in a previous or concurrent transaction, or atransaction number.

In other aspects, the invention encompasses data processing systemscomprising logic modules implemented at least partially by one or moreprocessors, as well as memories and other computer-readable mediaconfigured to carry out the foregoing steps.

2.0. Structural Overview

2.1. Architecture for Reporting of Transaction Data by Retailer

FIG. 13A illustrates a system 1300 for providing offers based ontransactional data gathered from multiple different retailers 1310,according to an embodiment. System 1300 may be used in connection withvarious embodiments described herein.

Retailers

System 1300 is used by multiple retailers 1310, each of which operates adifferent retail data center 1320. Each retail data center 1320comprises one or more computing devices and one or more databases thatcollectively operate as a retail server. Each retail data center 1320 iscommunicatively coupled to one or more brick-and-mortar stores 1330and/or online stores 1332 via wired, wireless, or any other type orcombination of communication channels, networks or lines.

Each retail data center 1320, among other aspects, receives transactiondata from stores 1330 and/or 1332. The transaction data may be generatedby payment terminals 1340 at stores 1330, or by websites or web-basedapplications at online stores 1332. Payment terminals 1340 may be anydata processing system or logic module capable of interfacing with aconsumer (e.g., a person purchasing an item in a grocery store), or withan individual assisting a consumer (e.g., a checkout cashier), for thepurpose of conducting a transaction, as described herein. For example,payment terminals 1340 may be specialized point-of-sale registers orself-checkout stands. Payment terminals 1340 may also or instead beadd-on devices that interface with existing point-of-sale registers orself-checkout stands.

Each store 1330 may further optionally operate a store controller systemthat interfaces with the various terminals 1340. The store controllermay, in concert with retail data center 1320, assist the terminals 1340in conducting transactions, including by providing information aboutitems and offers, as well as by providing payment processing services.These payment processing services may themselves interact with thirdparty payment systems, such as provided by credit card processingservices or banks. Such communications may take place via one or moreapplication programming interfaces (APIs), and may use one or morenetworks or communication channels.

The store controller may collect transaction-related data 1345 from theterminals 1340 and forward it in real time, near real time, or at alater time to a respective data center 1320. This information issometimes denoted contextual transaction data. In various embodiments,contextual transaction data 1345 may include any of a variety ofinformation related to one or more consumer transactions conducteddirectly or indirectly by a retailer. Examples of contextual transactiondata 1345 include data originating directly or indirectly from anytransaction conducted electronically or physically, over an electronicmedium or in a facility owned, controlled or operated by retailer, suchas retailer 1310, including without limitation basket-level transactiondetails such as universal product codes and quantities purchased, totalnumber of items purchased, transaction amounts, payment details (e.g., acredit card number, a payment identifier, a secure payment hash key),information about a data processing system, logic module or facilitywhere the transaction takes place (e.g., terminal 1340 or store 1330),time, date, offers applied during the transactions, information relatingto the customer conducting the transaction (e.g., a name, a phonenumber, a pin number, a password, a code, a loyalty card number, otherbiometric or personal identification data, etc.), RFID data, a deviceidentifier, items that were purchased in a previous or concurrenttransaction, a transaction number, and any other type or class ofsimilar data.

In one embodiment, the contextual transaction data 1345 is received viaan application programming interface (API) from a retailer POS or otherfacility. In one embodiment, the contextual transaction data 1345 isreceived in connection with a request for an offer recommendation. Inone embodiment, the contextual transaction data 1345 is receivedindependent of a request for an offer recommendation.

Transaction Aggregation

In one embodiment, each retail data center 1320 is also communicativelycoupled to a transaction aggregation system 1350 via wide area networksand/or direct lines. The retail data centers 1320 forward some or all ofthe contextual transaction data 1345 received from their respectivelycorresponding stores to the transaction aggregation system 1350. Invarious embodiments, contextual transaction data 1345 may be transmitteddirectly or indirectly to any other data processing system, such as areceipt server (e.g., receipt server 1370), an offer server (e.g., offerserver 1380), an advertisement server or platform (e.g., ad platform1390), or other data processing system or platform adapted to process ortransmit transaction-related information. The contextual transactiondata 1345 may be processed at the retail data center 1320, or may beunprocessed. The contextual transaction data 1345 may be forwarded inreal time as it is received, in near-real time, or batched and forwardedat regular intervals.

Transaction aggregation system 1350 is a data processing system, whichmay comprise one or more data processing systems and/or logic modules,and which implements a transaction aggregator 1360 for processing avariety of transaction data as the data arrives and/or causing suchtransaction data to be stored in transaction data store 1355.Transaction aggregation system 1350 may be operated by an offerdistributor, a payment provider, a retailer, a third-party serviceprovider, or any other entity that is involved in the process ofgenerating, storing, processing or distributing offers.

In general, the data processed and/or stored by the transactionaggregation system 1350 or by another data processing system involved inoffer generation, storage, processing or distribution may includevarious transaction attributes that are associated with historicaltransactions that occurred in the past (sometimes denoted “historicaltransaction attributes” or “historical transaction records”). Historicaltransaction records may include various classes of information thatrelate to users, transactions, vendors, payment processing, and anyother aspects of electronic or physical commerce. As an example,historical transaction records may be, or may include contextualtransaction data 1345 that was generated in connection with previoustransactions, has been stored in a memory, may have been furtherprocessed and refined, and which can now be retrieved and used as abasis for further data processing and decision making. As anotherexample, historical transaction records may be, or may includetransaction data 1355, consumer data 1358, product data 1354, and offerdata 1385. Historical transaction records may include contextualtransaction data 1345 or any associated data or derivative data that hasbeen generated up to a current moment in time.

Over one or more network interfaces, transaction aggregator 1360 mayprovide one or more application programming interfaces (APIs). In oneembodiment, an API used to receive historical transaction records isdenoted a transaction reporting application programming interfaces(APIs). The data centers 1320 may use transaction reporting applicationprogramming interfaces to report transaction logs, which may includetransaction records associated with historical transactions, totransaction aggregator 1360. The stored transaction data may comprisetransaction logs and other aggregated transaction data from the multipleretailers 1310. In some embodiments, transaction aggregation system 1350functions as a coordinating server within the meaning described in othersections.

In various embodiments, the transaction records associated withhistorical transactions may include transaction data 1355, consumer data1358, product data 1354, and/or any other types of data relating tohistorical transactions. These classes of data may be stored in one ormore databases, or in the same database, which may be physically storedone or more memories. Examples of memories that could be used to storesuch historical transaction records are discussed in connection with theembodiment of FIG. 9.

Transaction aggregator 1360 causes various transaction data intransaction data store 1355 to be stored in association with consumerentities described by consumer data in consumer data store 1358. It willbe noted that for simplicity, with respect to customer data store 1358and other data stores described herein, that the same label is usedherein to refer to both the data store and the data stored therein.Consumer data store 1358 includes records such as consumer records bywhich transaction data in transaction data store 1355 may be matched tospecific consumer entities. Examples of such transaction records thatrelate to consumer records include account identifiers, credit cardnumbers, names, pin numbers, passwords, personal codes, loyalty cardnumbers, email addresses, phone numbers, location information, and soforth.

Consumer data store 1358 may further include identifying data by whichconsumer devices 1305 may become associated with specific consumerentities, including without limitation IP addresses or other deviceidentifiers, user names, passwords, phone numbers, and locationinformation. Transaction aggregator 1360 may further update consumerentity definitions in consumer data store 1358 based on the transactiondata. Consumer data store 1358 and transaction data store 1355 may bestored in a same or different database system.

In an embodiment, consumer data store 1358 may be periodically seededwith account data collected directly from retailers 1310 or otherpartners, including social media networks and other websites. Forexample, a retailer 1310 may send the transaction aggregation system1350 consumer records based on its loyalty card account program on aweekly basis. In an embodiment, consumer data 1358 may also or insteadinclude registration information from consumer interactions with receiptserver 1370, offer server 1380, or a payment system. For example, offerserver 1380 may feature a registration process during which consumersoptionally enter information such as names, loyalty card identifiers,addresses, and so forth. In other embodiments, consumer data 1358 merelyincludes information collected from the transaction data.

Product data store 1354 may include information about a plurality ofdifferent items, including both goods and services, that may be found inreceipts or that may be the subject of an offer. The information mayinclude identifiers such as Universal Product Codes (UPCs) and/orstock-keeping unit (SKU) numbers, taxonomical categorizations, names,descriptions, nutritional information, product specifications, pricehistories, inventory levels, and/or any other suitable metadata. Theproduct information may be populated and maintained using any suitabledata collection technique. For example, the product information may becollected from and/or updated by retailers 1310 in periodic batchsynchronizations of retailer product databases. As another example,product information may be collected from data mining of retailer ormanufacturer websites. The product information may also or instead beupdated by transaction aggregation system 1350 as part of analyzingtransaction data 1355. Information from product data store 1354 may beutilized to enhance receipts presented by receipt server 1370. Forexample, a line item for a particular UPC in a receipt may include orlink to nutritional information or price history comparisons collectedin association with that UPC in product data store 1354. Similarinformation may be provided in association with offer recommendationsfrom offer server 1380 or advertisements presented by ad platform 1390.

In various embodiments, the consumer data 1358 and/or product data 1354may or may not be obtained from actual historical transactions in wholeor in part (e.g., at least part of the consumer data may have beenretrieved from a separate commercial or governmental consumeridentification database), but could nevertheless be considered to betransaction records associated with historical transactions, or may beused similarly and along with other transaction records associated withhistorical transactions.

Receipt Server

Transaction aggregation system 1350 further comprises a data processingsystem or logic module, which may provide various receipt-relatedfunctionality, and which is denoted in FIG. 13A as receipt server 1370.Receipt server 1370 has one or more network interfaces (which may or maynot be the same as those that belong to the transaction aggregator 1360)over which receipt server 1370 may transmit or otherwise make availableto consumer devices 1305 receipts from one or more of the retailers 1310based on various transaction records associated with historicaltransactions, including the transaction data in transaction data store1355 and the consumer entity data in consumer data store 1358. Receiptsmay be provided using any of the techniques described herein.

Offer Server

System 1300 further comprises a data processing system or logic module,which may provide various offer-related functionality, and which isdenoted in FIG. 13A as offer server 1380. Offer server 1380 may transmitor otherwise make available offers to consumer devices 1305. Offerserver 1380 may be operated by offer distributor, a payment provider, aretailer, a third-party service provider, or any other entity that isinvolved in the process of generating, storing, processing ordistributing offers. Consumer devices 1305 need not necessarily belongto a specific consumer, and may in fact be any device with which aconsumer interacts. Consumer devices 1305 may include, for instance,desktop computers, laptop computers, ultrabooks, tablets, smartphones,personal wearable data processing systems, virtual reality augmentationdevices (e.g., wearable glasses with electronic data processingfunctionality), checkout or other kiosks at retail stores or gasstations, automated teller machines (“ATM”), parking meters, receipt orticket printers, drive-through menu boards, free-standing interactivedisplays in public areas or at public events, and so forth.

The act of providing an offer may include providing offer datadescribing an offer and/or providing a mechanism by which a consumer mayredeem the offer, such as a mechanism for printing a coupon, displayinga coupon in a digital format, or saving information identifying theoffer to an account associated with the consumer. Offer server 1380 maybe, for example, one or more computing devices that collectivelyfunction as a server. Offer server 1380 includes one or more networkinterfaces (which may be the same as or different from those oftransaction aggregation system 1350) over which it receives requests foroffer(s) from consumer devices 1305 and/or other servers. In anembodiment, offer server 1380 provides or uses an offer recommendationapplication programming interface by which it receives the requestsalong with, optionally, context information for identifying a consumerentity that corresponds to the request. For example, each request mayinclude information provided by a corresponding consumer device 1305,such as user login credentials, phone numbers, device identifyinginformation such as an Internet Protocol (“IP”) address or Near FieldCommunication (“NFC”) tag, biometric data, basket data, shopping listdata, or request metadata, by which the offer server 1380 may identify,or guess, a consumer entity for which offer server 1380 is to provide anoffer. In an embodiment, offer server 1380 is a web server that providesoffers embedded within web pages, images, or other containers suitablefor presentation at a web client. In an embodiment, offer server 1380provides raw offer data in formats or protocols that are not intended tobe presented directly by the requestor, such as XML, SOAP, JSON, and soforth. The requestor then processes this raw offer data and generatesits own presentation of the offers identified by offer server 1380.

Offer server 1380 accesses records describing offers within an offerdata store 1385, which may have been populated with data from offerproviders and/or offer aggregation services. For example, offer server1380 may provide an offer aggregation component that interfaces with orcollects data from offer providers describing specific offer campaigns.Offer server 1380 compares data from offer data store 1385, transactiondata store 1355, and consumer data store 1358 to match one or moreoffers to specific requests for offers. Depending on where offer server1380 is deployed, offer server 1380 may communicate directly withconsumer data store 1358 and/or transaction data store 1355, or offerserver 1380 may request data via the transaction aggregation system1350. In an embodiment, when providing a consumer with an offer, offerserver 1380 bases the selection of the offer on transaction data fromtransactions by the consumer at two or more different more differentretailers 1310.

Offer server 1380 may receive requests for offer recommendationsdirectly from consumer devices 1305. Offer server 1380 may also orinstead receive requests from other servers that are interfacing withdevices operated by consumers 1305, including receipt server 1370 and/orad platform 1390. In an embodiment, offer server 1380 may notnecessarily return any information to consumer device 1305, but rathersimply activate the offer(s) selected in response to the request. Forexample, if the consumer device is a public kiosk that generated therequest in response to detecting the swipe of an NFC-bearing device, theoffer server 1305 may simply generate a digital coupon for the consumerentity most likely to be in possession of the NFC-bearing device withoutproviding any information about the selected offer to the kiosk.

In some embodiments, a coupon server such as described herein mayfunction as an offer server 1380. In other embodiments, a coupon serverdistributes coupons separately from the offer server 1380. That is,offer server 1380 simply identifies and provides information aboutoffers in response to requests for offers. A consumer device 1305separately accesses a coupon server if the consumer device 1305 is toobtain a coupon for an offer recommended by offer server 1380.

Offer server 1380 and/or a separate coupon server also generate andaccess records in an offer activation data store 1388. The records inoffer activation data store 1388 indicate which offers described inoffer data store 1385 have been “activated” for which consumer entitiesdescribed in consumer data 1358. An “activated” offer for a particularconsumer entity is an offer that a consumer entity may be specificallyeligible to redeem at one or more of retailers 1310. An offer may beactivated for a specific set of one or more retailers 1310, or for allretailers 1310 in general. An activated offer can be mapped directly toa consumer entity in consumer data store 1358, or to one or morespecific data elements associated with that consumer entity, such asloyalty card identifiers, store account numbers, or householdidentifiers.

An offer can become activated in response to a number of triggeringevents, including upon recommendation by the offer recommendationcomponent of offer server 1380, upon a consumer device 1305 requestingactivation of an offer provided by offer server 1380, upon a consumerdevice 1305 printing or digitally clipping an offer, in response to aspecific request to the offer server 1380 from an offer provider orother entity, in response to an automated activation process such asschedule or event-based triggers, and so forth. Since the act ofactivating an offer often involves a coupon, the acts of “activating acoupon” and “generating a coupon” for a consumer should be understood torefer to or imply the activation of the corresponding offer for thatconsumer. In fact, in an embodiment, a record describing an activatedoffer is considered to be equivalent to a digital coupon for that offer.In an embodiment, a record describing an activated offer is used tovalidate a printed coupon. In an embodiment, a digital coupon isgenerated on-demand, upon a retailer 1310 determining that a transactioninvolving the corresponding consumer entity record matches theconditions for an offer that has been activated for the consumer entity.In some embodiments, certain offers are “globally activated” for allconsumers, in that a consumer may redeem the offer without the offerhaving been specifically activated for the consumer entity.

In one embodiment, in addition to information relating to offeractivations, a data processing system also utilizes other informationregarding offers, including information relating to offer impressionsand offer redemptions. Offer activations, impressions and redemptions,together with associated types of data and data attributes and records,are further discussed in connection with various embodiments.

In an embodiment, offer server 1380 and receipt server 1370 are in factthe same server. In other embodiments offer server 1380 and receiptserver 1370 are separate and distinct servers, and may even be operatedby different providers. In an embodiment, multiple different offerservers 1380 may make use of the transaction data in transaction datastore 1355.

In an embodiment, the data in offer data store 1385 and/or offeractivation data store 1388 is accessible by or shared with retail datacenters 1320 or other components of retailers 1310. For example, offerserver 1380 may provide or may use an API by which stores 1330 mayrequest offer data for offers identified by consumers in real-time. Asanother example, offer server 1380 may periodically send offer datadescribing available offers to retail data centers 1320, which in turnmay synchronize the offer data with their own local repositories ofoffer data. The retailers 1310 may further be provided with offeractivation data from offer activation data 1388, either on demand or inperiodic batches, to assist the retailers 1310 in determining whether aparticular consumer is eligible for particular offers. Retailers 1310may further remove activated offers from offer activation data store1388 upon a consumer redeeming an activated offer. The removal may beaccomplished by a direct communication with offer server 1380, offerdata store 1385, or other suitable component, or indirectly as a resultof providing transaction data to transaction aggregation system 1350. Inan embodiment, activated offers are not deleted from offer activationdata 1388, but rather simply marked as redeemed for tracking and otherpurposes. In other embodiments, offer tracking data is stored separatelyfrom offer activation data.

Ad platform 1390 is a set of one or more data processing systems orlogic components that deliver ads to consumers via, for instance,websites or mobile applications. Offer server 1380 may be part of adplatform 1390, or may be entirely separate from offer server 1380. Offerserver 1380 and ad platform 1390 may be operated by the same entity, orby different providers.

In various embodiments, one or more data processing systems or logicmodules may be adapted to generate, select, modify, store, processand/or distribute receipts and/or offers to consumers and/or retailersbased on various transaction records associated with historicaltransactions.

For example, with reference to the embodiment of FIG. 13A, the receiptserver 1370 may generate, select, modify, store, process and/ordistribute receipts based on consumer data 1358, transaction data 1355,and product data 1354. Such receipts may also include offer informationthat is produced based on offer data 1385. Further, the generation,storage, modification, selection, processing and/or distribution of suchreceipts may also be based on offer data 1385 (e.g., depending on whichoffers are available, the content, availably, manner of distribution orother aspects of the receipt may be adjusted). As another example, withreference to the embodiment of FIG. 13A, the offer server 1380 maygenerate, select, modify, store, process and/or distribute offers basedon consumer data 1358, transaction data 1355, product data 1354, andoffer data 1385.

Offer server 1380 may further have access to a number of data sourcesfor various uses, including offer targeting and offer recommendation.One example of such a data source is the optional product data store1354. Other examples of such data sources may include, withoutlimitation, an offer tracking data store, a shopping list data storecomprising shopping list data collected from shopping list applicationson consumer devices 1305, a web history data store, an event log datastore as described in other sections, a location history data store, aweather data store, and so forth.

In various embodiments, one or more data processing systems or logicmodules, such as offer server 1380, receipt server 1370 or ad platform1390, may be adapted to generate, select, modify, store, process and/ordistribute receipts and/or offers to consumers and/or retailers based onboth (a) contextual transaction data 1345 and (b) historical transactionrecords.

FIG. 13B is a different view of system 1300 for providing offers basedon transactional data gathered from multiple different retailers 1310,according to an embodiment.

As depicted in FIG. 13B, a retailer 1310 features retail data center1320, stores 1330, online store 1332, and terminals 1340. Retailer 1310further implements a retailer site 1334. Retailer site 1334 is a website operated by the retailer, potentially in association with onlinestore 1332, for distributing offers. Retailer 1310 may utilize site 1334to distribute offers from offer distribution system 1352. Optionally,retailer 1310 may distribute offers from other sources utilizing site1334. Retailer 1310 may further utilize site 1334 to distribute receiptsstored in transaction data 1355. The receipts distributed at site 1334may or may not include embedded offers from offer data 1385. Retailer1310 may rely upon offer distribution system 1352 to provide code and/ortemplates for presenting offers, or site 1334 may arrange its ownpresentations of offers and/or receipts.

Consumers interact with the retailer 1310 for various purposes at site1334, terminals 1340, or online store 1332. The interactions may involvea consumer device 1305 that functions, among other purposes, as anendpoint for receiving offers. Or, the consumers may interact directlywith terminals 1340, or personnel operating terminals 1340.

As depicted in FIG. 13B, system 1300 comprises an offer distributionsystem 1352. The offer distribution system 1352 is a set of one or moreserver computing devices and data repositories that implement thedepicted components. For example, the offer distribution system mayfurther comprise offer server 1380 and receipt server 1370 illustratedin the embodiment of FIG. 13A. The server computer devices may beco-located in a single data center, or the components may be distributedacross multiple locations. In either case, the offer distribution system1352 may be operated under the control of an offer distributor that isdifferent from a retailer 1310 or provider 1395. Offer distributionsystem 1352 comprises, among other elements, transaction data 1355,offer data 1385, user data 1358, product data 1354, and offer activationdata 1386.

Retailer 1310 uses various interfaces of offer distribution system 1352to distribute offers and receipts, upload transaction data, and redeemactivated offers. These interfaces include a receipt interface 1371 toreceipt server 1370, a transaction interface 1361 to transaction data1355, an offer distribution interface 1381 to offer data 1385, aconsumer resolution interface 1357 to user data 1358, a product datainterface 1353 to product data 1354, and an activation/redemptioninterface 1387 to activation data 1386. The interfaces may comprise anysuitable combination of APIs, ports, protocol handlers, server-sidelogic, and network components.

The retailer 1310 accesses the interfaces of offer distribution system1352 over a network for various interactions between retailer 1310 andcomponents such as offer server 1380, receipt server 1370, andtransaction aggregator 1360. For example, retail data center 1320 and/orother components of retailer 1310 may utilize consumer resolutioninterface 1357 to upload consumer data collections, resolve the identityof a consumer that is operating a consumer device 1305 or transactingwith a terminal 1340, and/or request data associated with a consumerentity. Retail data center 1320 may further upload product data foroffer distribution systems 1352's records through product data interface1353. Retail data center 1320 may further upload transaction datathrough transaction interface 1361. Retail data center 1320 maycommunicate through offer distribution interface 1381 to learn offerterms. Retail data center 1320 may communicate throughactivation/redemption interface 1387 to identify offers for which aconsumer is eligible and/or to report redeemed offers. Retail site 1334or other components of retail data center 1320 may communicate viareceipt interface 1371 and offer distribution interface 1381 to obtainreceipts and offers respectively. Offer distribution system 1352 mayfeature yet other interfaces for other purposes. Other exampleinteractions are described through this application.

Again, system 1300 is but one example of system for practicing thetechniques described herein. Other systems may include additional orfewer elements in potentially varying arrangements. For example, theoffer distribution system 1352 may not necessarily comprise componentsof transaction aggregation system 1350. As another example, some or allof the retailers 1310 may not necessarily utilize the same architectureas depicted in FIG. 13B. For instance, some retailers 1310 may lack aretail site 1334 or online store 1332, while others may lack terminals1340. As another example, the offer distribution system 1352 need notprovide each and every interface depicted in FIG. 13B. Moreover, in someembodiments, FIGS. 13A and 13B are actually views of different systems.Also, the logical division of functions between the interfaces describedabove need not be exactly the same as depicted.

Variations

System 1300 is but one example system for providing offers based oncross-retailer transactional data. Other systems may involve fewer,additional, and/or different elements in potentially varyingarrangements. For example, other systems may involve many more retailers1310 having many more stores 1330 and/or additional online stores 1332.Additional consumers 1305 may access offer server 1380 and/or receiptserver 1370 with additional devices. As another example, in anembodiment, payment terminals 1340 are configured to communicatedirectly with transaction aggregator 1360 over a wide area network. Forinstance, payment terminals 1340 may be specialized terminals deployedby, and potentially even subsidized by, the operator of transactionaggregation system 1350. In an embodiment, some or all retailers 1310may not have a retail data center 1320. Rather, individual stores 1330and/or 1332 communicate directly with transaction aggregation system1350.

In an embodiment, offer server 1380 communicates with retailer datacenters 1320 to recommend offers that retailers 1310 may make availableto certain consumers. For example, retailers 1310 may deployinformational kiosks throughout a store with which consumers mayinteract. Retailers 1310 may send information collected from consumersby these kiosks to offer server 1380, which in turn may then provideoffer data describing one or more recommended offers to the kiosk. Theoffer data may then be displayed at the kiosk. Similarly, recommendedoffer data may be returned to a store clerk or other employee based oninformation that the consumer has provided. The employee may thenrecommend an offer to the consumer. Such a technique could be used for avariety of purposes—for example, offers may be recommended at a checkoutstand to encourage additional purchases, or an offer may be suggested bya salesperson to “close” a deal on an item that the consumer appearshesitant to purchase. Similar techniques may also be used to recommendoffers on a store website.

In an embodiment, retailers 1310 or another entity, such as a paymentsystem, may include a website that delivers receipts and/or offers toconsumer devices 1305. For example, the website may include a receiptgeneration application that retrieves receipt data from receipt server1370 via a suitable API, and then formats the receipt data to fit aretailer-specific template. Similarly, the website may include an offerprovision application that requests offer data for certain consumersfrom offer server 1380, and then reformats those offers to be embeddedwithin a retailer's website. Offers from offer server 1380 may co-existwithin such a website along with offers from other sources, includingretailer-specific offers that are not distributed by offer server 1380.In an embodiment, similar levels of customization may be achieved by aretailer or other entity providing receipt server 1370 or offer server1380 with template data that instructs the receipt server 1370 or offerserver 1380 how to present receipts and offers that are specific to thatentity.

2.2. Architecture for Reporting of Transaction Data by Payment Provider

FIG. 14 illustrates a system 1400 for providing offers based ontransactional data gathered by a payment system 1450 from multipledifferent retailers 1410, according to an embodiment. System 1400comprises many of the same components as system 1300. However, whilesystem 1400 may certainly also be utilized by the retailers 1310 of FIG.13A, FIG. 14 depicts retailers 1410 instead of retailers 1310. Retailers1410 are similar to retailers 1310, in that they may deploy retail datacenters 1420, stores 1430, online stores 1432, and/or terminals 1440.However, retailers 1410 do not communicate directly with transactionaggregation system 1350. Rather, retailers 1410 communicate only withpayment server 1460 of payment system 1450.

Payment system 1450 may be a system of one or more server-basedcomputing systems that execute services for authorizing and processingpayments to retailers 1410 for transactions between retailers 1410 andconsumers. Payment system 1450 may be operated by a third-party paymentDuring transactions with consumers at stores 1430 or 1432, consumers mayattempt to pay by credit card, debit card, or other electronic paymentmechanism. Terminals 1440 or online stores 1432 are configured toreceive input from a consumer identifying the payment mechanism. Theinput may include credentials such as a credit card number andverification code, a phone number and personal identification number(PIN), information collected from a magnetically swiped credit card,information collected from a NFC transmitter on the consumer's device1305, and so forth. Along with transaction data such as described withrespect to system 1300, the credentials are transmitted over anappropriate communications network to payment server 1460. Thecredentials may be transmitted by any of terminals 1440, store 1430, orretail data center 1430, depending on the embodiment. The payment server1460 authenticates the credentials and then determines whether anaccount associated with the credentials has sufficient funds or creditfor the transaction indicated by the transmitted transaction details.The payment server 1460 returns data to retailer 1410 indicating whetherthe transaction is authorized. If the transaction is authorized, paymentserver 1460 also takes steps to transfer appropriate payment to retailer1410, bill the consumer account corresponding to the credentials, and soforth.

System 1400 may include a number of different payment systems 1450, eachconfigured to authorize and process payments using different paymentmechanisms. For example, system 1400 may include payment systems 1450from different credit and/or debit card processors, online paymentprocessors, banks, retailers, and so forth. Transactions in system 1300of FIG. 13A may likewise have involved one or more payment systems that,like payment system 1450, are configured to authorize and processpayments. However, payment system 1450 is additionally configured as anintermediary between retailers 1410 and transaction aggregation system1350 and/or offer server 1380.

In an embodiment, payment system 1450 collects basket data from thetransactions conducted by retailers 1410. Whereas conventional paymentsystems are typically ambivalent as to the basket-level details of thetransactions for which they process payments, the various paymentauthorization protocols and interfaces utilized by payment server 1460may be configured to allow for the receipt of basket-level details inassociation with a payment authorization request. Payment system 1450may then send all of the transaction details for a transaction,including the basket-level details, to transaction aggregation system1350.

In an embodiment, payment system 1450 additionally facilitates theredemption of offers based on transaction details received from retailer1410. For example, payment system 1450 may identify a consumer entityassociated with a transaction and access offer activation data for thatconsumer entity. Prior to authorizing and processing payment, paymentsystem 1450 may automatically apply to the transaction any activatedoffers for items being purchased in the transaction. If payment isauthorized, payment system 1450 then returns offer redemptioninformation to the retailer 1410 so that the retailer 1410 may requestreimbursement for the redeemed offer and, if necessary, provide theconsumer with any additional items to which the consumer may be entitledas a result of redeeming the offer.

In an embodiment, retailer 1410 may receive full payment for atransaction as if no offer had been applied, and payment system 1450 mayinstead request reimbursement for a redeemed offer itself. In one suchembodiment, the retailer may not even be unaware that an offer wasredeemed. In another such embodiment, the payment system 1450 mayinclude data indicating both how much the retailer is receiving for thetransaction (the transaction total before applying the offer), and howmuch the consumer actually paid (the transaction total after applyingthe offer). Thus, the retailer 1410 may indicate to the consumer that anoffer was applied, even though retailer 1410 did not apply the offer.

In an embodiment, payment system 1450 does not apply the offer at thetime of the transaction. Rather, payment system 1450 subsequentlyapplies the offer by reducing the amount billed to the consumer in astatement, making other adjustments to a statement, and/or providing areward such as credit card points or additional offers. The paymentsystem 1450 may notify the consumer when the offer has been applied byemail, text, or the statement itself. Since the offer is not beingredeemed as part of the transaction, payment system 1450 may thus delayapplication of an offer until an arbitrary time after conclusion of thetransaction. For example, the payment system 1450 may periodicallyanalyze transactions to determine whether any offers should be applied.Or, payment system 1450 may allow an issuing bank, offer provider, orother third-party to analyze transactions and inform payment system 1450when an offer should be applied.

In an embodiment, payment system 1450 may be configured only to collecttransaction details. If offers from offer server 1380 are to be appliedto a transaction, a retailer 1410 is configured to access offer dataindependently of payment server 1450. In an embodiment, the reverse istrue. That is, payment system 1450 is configured only to apply offersfrom offer server 1380, and retailers 1410 communicate transactiondetails to transaction aggregation system separately from payment system1450. In an embodiment, both payment system 1450 and retailers 1410 maybe configured to apply offers from offer server 1380. For example,certain types of offer may be applied at the time of a transaction byretail data center 1420, while other types of offers may subsequently beapplied to a credit card statement by payment system 1450.

In an embodiment, payment system 1450 does not receive basket data fromretailers 1410. Payment system 1450 may still be configured to reportaggregate transaction details to transaction aggregation system 1350and/or apply offers from offer server 1380 that are conditioned uponaggregate transaction details rather than basket-level transactiondetails.

In an embodiment, mobile payment techniques may be employed by theconsumer. Such techniques may involve the consumer device 1305communicating certain credentials and/or transaction details to thepayment system 1450. The consumer device 1305 may also interact withterminals 1440. In an embodiment, consumer device 1305 may providepayment server 1460 or terminals 1440 an indication of which activatedoffers the consumer wishes to apply to a transaction. For example, theconsumer device 1305 may include a mobile payment application thatinterfaces with offer server 1380, from which the consumer may selectdigital offers that the consumer wishes to apply the transaction.

In an embodiment, transaction aggregation system 1350 may in fact bepart of payment system 1450. In an embodiment, offer server 1380 may beconfigured to access data from transaction data stores 1350 and/ormultiple consumer data stores 1358 from multiple transaction aggregationsystems 1350. Offer server 1380 may further be configured to cachecopies of this data locally. In an embodiment, a receipt server 1370 maybe part of the payment system 1450, instead of or in addition totransaction aggregation system 1350.

In some embodiments, systems 1300 and 1400 may in fact be the samesystem, having different retailers 1310 and 1410 for which transactiondata is collected and/or offers are redeemed in different manners. Thus,the collection of transaction data as described herein is not limited toany specific technique, but rather may take varying forms depending onthe specific embodiment. Similarly, the process of applying andredeeming an offer may occur in a variety of ways depending on thespecific embodiment. For simplification, the techniques described hereinwill often describe the sending of transactional data or the applicationof an offer as being performed by the retailer. However, unlessotherwise noted, these techniques are equally applicable when thetransactional data is sent by the payment provider or other third party,and/or when an offer is applied by a payment provider or other thirdparty.

2.3. Consumer Entity Resolution Architecture

FIG. 34 illustrates a system 3400 for distinguishing between consumersto resolve consumers to unique consumer identities that span recordsfrom multiple sources, according to an embodiment. System 3400 is butone example of a system for differentiating between consumers andmapping different consumers to unique identities. Other systems mayinclude additional or fewer elements in potentially varyingarrangements.

The embodiment illustrated in FIG. 34 shows entities 3410 a-c, such asretailers 1310 or other suitable sources of consumer data as describedherein. Retailers 3410 a-c maintain, produce and/or transmit customerrecord collections 3430 a-c, respectively. Each customer recordcollection comprises a set of customer records. Each customer recordcollection comprises a set of data fields, including one or more fieldsfor customer identifiers or other credentials. In one embodiment, eachdata field of a customer record collection applies to each customerrecord in that collection. In one embodiment, one or more customerrecords in a collection may not have a particular data field otherwisepresent in that collection. The fields of data may also include avariety of other data, such as demographic information. The retailers3410 upload a set of consumer records, such as the record collections3430, or portions thereof, to an offer server and/or a transactionserver via a customer record upload interface 3420 of system 3400. Insome embodiments, the customer record upload interface 3420 may requirethat the collections 3430 be converted to a certain format beforeupload. In other embodiments, a customer record normalization componentmay perform any needed conversions after the upload.

In general, a data field used in a consumer record collection mayinclude any type of information that directly or indirectly relates tothe consumer. Examples of such information that could be stored in amemory and associated with a consumer record or data field includeincluding biographical data, past transactions, past offers activated orredeemed, relationships with other consumers, and so on. In general, adata field used in a consumer record collection may include any of thehistorical transaction records discussed in connection with theembodiment of FIG. 13A, to the extent such historical transactionrecords relate directly or indirectly to consumers or transactionsconducted by consumers, and any other similar types of information.

System 3400 further comprises a master customer record generator 3440that analyzes the sets of customer records for correlations 3435 betweencustomer records, using any suitable technique. For example, recordshaving certain common values for certain similar fields may becorrelated. More complicated correlations 3435 are described insubsequent sections. The master customer record generator 3440 uses thecorrelations to create a refined set of customer records, denoted asmaster customer record collection 3450. In one embodiment, in mastercustomer record collection 3450 there is a single master record for eachcorrelation 3435 that is linked to the correlation 3435 and sourcerecords from which it was derived. Each master customer record comprisesa value for each field in the customer records of collections 3430. Forfields that are similar between collections, a master customer recordmay only have one field. If the values of the similar field aredifferent between correlated records in different collections, trustscores and/or confidence scores associated with the fields and/orcollections, as described herein, are used to select the value(s)associated with the master customer record. Master customer records mayalso be generated for customer records in collections 3430 that were notcorrelated. Collections 3430 may be updated and/or re-uploaded overtime. Consequently, the master customer record generator 3440 may updatecorrelations 3435 and master customer record collection 3450 in responseto any changes in collections 3430.

System 3400 further comprises a customer record resolver 3460 thatanalyzes the master customer record collection 3450 to match credentialsto particular master customer records. The customer record resolver 3460may do so at the request of, among other components, servers 3480, suchas offer servers or transaction servers. The servers 3480 may obtain thecredentials from messages 3490 that contain or are associated withcredentials. A variety of such messages are described herein, includingrequests for offer recommendations or targeted offers, requests toaccess activated offers for a consumer, transaction logs, event logs,and so forth.

By matching a master customer record to a set of customer contextualdata (e.g., user credentials), the customer record resolver 3460 maydetermine a consumer entity that is associated with a message 3490. Thecustomer record resolver 3460 identifies this entity to servers 3480,and servers 3480 then access information associated with the entity,such as values from fields of the master customer record, transactiondata aggregated from transaction logs 3455 that have also been resolvedto the same customer entity, and/or offer activation data and otherinformation from offer tracking data 3485 that is associated with thesame customer entity. The servers 3480 may then take action upon themessage 3490 based on the data associated with the entity.

In various embodiments, a logic module, such as the customer recordresolver 3460, compares a set of customer contextual data received froma remote source (e.g., from a retailer) or retrieved from a memory(e.g., from a database) against one or more of the master customerrecords stored in the master collection of customer records to uniquelyidentify the respective consumer. In one embodiment, the customercontextual data is received as part of a message 3490. Examples ofsuitable customer contextual data that may be used to facilitateidentification of customer identities were discussed in connection withother embodiments, including, including, for example, the contextualtransaction data 1345 discussed in connection with the embodiment ofFIG. 13. In various embodiments, such suitable customer contextual datamay include basket-level transaction details such as universal productcodes and quantities purchased (e.g., an older male consumer may tend topurchase different types of products than a younger female consumer),total number of items purchased, transaction amounts, payment details(e.g., a credit card number, a payment identifier, a secure payment hashkey), information about a data processing system, logic module orfacility where the transaction takes place, time, date, offers appliedduring the transactions, other information relating to the customerconducting the transaction (e.g., a name, a phone number, a pin number,a password, a code, a loyalty card number, other biometric or personalidentification data, etc.), RFID data, a device identifier, items thatwere purchased in a previous or concurrent transaction, a transactionnumber, and other similar types of information.

Additional examples of the functionality and operation of embodimentssimilar to the embodiment of FIG. 34 are provided in connection withFIG. 21.

2.4. Offer Definition Architecture

FIG. 15 illustrates an example system 1500 for defining offers,according to an embodiment. Other systems may include fewer or differentcomponents in varying arrangements. In an embodiment, other techniquesdescribed herein may be practiced with any suitable offer definitionsystem. In an embodiment, system 1500 is the same system as system 1300and/or system 1400. In other embodiments, system 1500 is different fromsystem 1300 and/or system 1400.

System 1500 comprises an offer distribution system 1550 operated by anoffer distributor. Offer distribution system 1550 is a system of one ormore computing devices that, among other aspects, facilitate thecreation of offer data as described herein, and further facilitate thedistribution of offers based upon that offer data. System 1500 is butone example of a system for creating offer data for use in the othertechniques described herein.

Offer Definition Interface

Offer distribution system comprises an offer definition interfacecomponent 1584, also known as an offer creation interface, with whichoffer providers 1595 may communicate over one or more networks. Offerdefinition interface component 1584 presents an interface comprisingcontrols by which offer providers may create and edit offer datadefining offers that offer providers 1595 wish to provide to consumersoperating consumer devices 1505. The controls presented by offerdefinition interface 1584 allow offer providers 1595 to define any of anumber of offer parameters, including an offer title, an offerdescription, offer terms, and so forth. Offer definition interface 1584may be a web interface hosted by a web server, an API accessed by athick-client, interface for receiving and processing data feeds, or anyother suitable interface.

In one embodiment, offer definition interface 1584 is a simple interfacein which an offer provider inputs a title, description, a set of UPCcodes or family codes, an expiration date, distribution limits, and anoptional list of eligible retailers. In some embodiments, offerdefinition interface 1584 may support the creation of offers havingterms of varying complexity. For example, in one embodiment, offerdefinition interface 1584 may support the creation of “dynamic” offers,whose terms vary for different consumers or products in accordance withrules or formulas defined through the offer definition interface 1584.In some embodiments, offer definition interface 1584 includes atargeting component that accepts as input one or more triggeringcontexts or events in response to which the offer should be provided.Optionally, offer definition interface 1584 supports the input of a“bid” indicating how much the offer provider 1595 is willing tocompensate the offer distributor for recommending, presenting, and/oractivating an offer. In some embodiments, the bid may differ dependingon the context in which the offer is presented.

When an offer provider 1595 has finished creating or editing an offer,offer definition interface component 1584 stores the offer in offer datastore 1585. Offer data store 1585 may include a repository of recordsdescribing the parameters of the offers that are to be or have beendistributed by offer distribution system 1550. Offer data store 1585 maybe similar to offer data store 1385.

Offer Server

The offer distribution system 1550 further comprises an offer server1580 which, for example, may be similar to the offer server 1380described in connection with the embodiment of FIG. 13A. Offer server1380 comprises one or both of a targeting engine 1580 a and arecommendation engine 1580 b. Targeting engine 1580 a matches targetedoffers described in offer data store 1585 to triggering events orcontexts, and provides the matching offers to the corresponding consumerdevices 1505. Recommendation engine 1580 b ranks offers described inoffer data store 1585 by various scoring mechanisms, and then recommendsthe offers to corresponding consumer devices 1505. When targeting engine1580 a and recommendation engine 1580 b co-exist in the same offerserver 1580, they may provide offers by the same distribution channels,or by separate distribution channels. For example, targeted offers maybe provided in one section of a website, while recommended offers may beprovided in a different section of the website. Examples of suitabletargeting engines 1580 a and recommendation engines 1580 b are describedin subsequent sections. In an embodiment, a universal scoring engine mayfunction as both targeting engines 1580 a and recommendation engines1580 b.

Offer server 1550 may further comprise an activation engine 1580 c.Activation engine 1580 c receives requests from consumer devices 1505 toactivate offers. For example, a consumer at consumer device 1505 may seean offer that was recommended by recommendation engine 1580 b and clickon the offer to issue such a request. Responsive to these requests,activation engine 1580 c activates offers, using one of the offeractivation techniques described herein. In an embodiment, activationengine 1580 c may further be configured to automatically activatecertain offers for certain consumers, without the consumers explicitlyrequesting activation. For example, automatic activation may betriggered by requests from offer providers and/or retailers, or inresponse to various rules such as described elsewhere in thisdisclosure. Activation engine 1580 c may further communicate informationabout activated offers to retailers 1510, and/or receive redemptioninformation indicating when an activated offer has been accepted.

Activation engine 1580 c may record activations and redemptions intracking data store 1588, which may be similar to the offer activationstore 1388 discussed in connection with the embodiment of FIG. 13A.Offer server 1580 may further store a variety of other offer trackinginformation in tracking data store 1588, such as the number of times anoffer has been presented, which is also referred to herein as the numberof offer impressions, or the number of times an offer has been clickedon, which in some embodiments may be different from the number of timesan offer has been activated. Offer server 1580 may utilize the trackingdata 1588 to derive signals for scoring functions, categorize consumersand/or events for offer targeting, enforce distribution limits, and soforth.

Reporting

Offer distribution system 1550 further comprises a reporting module 1589that analyzes the tracking data 1588, and optionally other data such astransaction data 1545, and provides reports based thereon to offerproviders 1595. For example, reporting module 1589 may periodicallydeliver reports indicating how many times certain offers have beenviewed, activated, or redeemed. As another example, offer providers 1595may log into reporting module 1589 and utilize a web-based interface todrill-down into aggregated transaction information that has beencorrelated with activations or redemptions of certain offers. Reportingmodule 1589 may also provide reports derived from transaction data orany logged events. In an embodiment, since the transaction data, offerdata, and events can be correlated to specific consumers having knowncharacteristics, reporting module 1589 may feature various controls forallowing offer providers 1595 to generate customized reports forprovider-defined consumer segmentations of both macro-level andmicro-level granularity. Performance of products and offers may begraphed for various time periods with respect to various consumergroupings and/or locations, to allow for quick comparison.

Data Stores

System 1500 may further comprise a transaction data store 1545 and aconsumer data store 1558, either of which may be stored internal orexternal to offer distribution system 1150, depending on the embodiment.Transaction data store 1545 comprises transaction records fromtransactions conducted by multiple retailers 1510. Consumer data 1558comprises consumer records populated by account data and otherinformation received from retailers 1510, and/or data collected fromother entities, including public records, personal data providers, oreven consumers themselves. Transaction data store 1350 and consumer datastore 1358 are examples of transaction data store 1545 and consumer datastore 1558, respectively.

Offer distribution system 1550 may further comprise any number of eventlogs 1556. Event logs 1556 may record any of a variety of events thatwere logged by offer distribution system 1550, or submitted to offerdistribution system 1550, including without limitation web-relatedrequests, location tracking data, shopping list changes, deviceinteractions, and notifications of inventory changes by refrigeratorsand other personal inventory tracking mechanisms. The events may furtherinclude transaction events, as well as offer impressions, activations,or redemptions. Hence, event logs 1556 may actually comprise transactiondata store 1545 and tracking data 1588, or a copy of at least a subsetthereof. Event logs 1556 record events that were potentially performedby consumers described in consumer data 1558. Based on identifiersrecorded within the event records, offer distribution system 1550 mayattempt to resolve the recorded events to specific consumer entitiesdescried in consumer data 1558. Targeting engine 1580 a may then useevent logs 1556 to recognize when a consumer matches a target associatedwith an offer. Recommendation engine 1580 b may then utilize event logs1556 to derive signals for scoring functions.

External Offer Aggregator

Offer distribution system 1550 may comprise an offer aggregator 1594that imports certain offers from other offer distributors 1592. Forexample, offer aggregator 1594 may receive submissions from or monitorfeeds, from other offer distributors 1592, that describe offers beingdistributed at those systems. Or, offer aggregator may data mine or“screen-scrape” offer distribution websites for other offers. The offerinformation from these sources may then be translated into structuressuitable for storage in offer data store 1585. In an embodiment, offerdistribution system 1550 may then distribute some or all of theseimported offers. Optionally, offer distribution system 1550 may evenreport distributions back to the other offer distributors 1592. In anembodiment, offer distribution system 1550 does not distribute some orall of the imported offers, but rather simply utilizes the offerinformation from these sources as a comparison point for offers createdby offer providers 1595 and/or to interpret transaction data 1545.

For example, offer distribution system 1550 may recognize in certaintransactions a redeemed offer that had been distributed by another offerdistributor 1592. The offer distribution system 1550 may be configuredwith logic for gauging the effectiveness of the imported offer. Theoffer distribution system 1550 may further use the information forpurposes such as suggesting offers for offer providers 1595 and/ordetermining whether to recommend future offers that are similar to theimported offer to a particular consumer device 1505. In an embodiment,offer distribution system 1550 may be configured to learn about outsideoffers from transaction data 1545 rather than importing directly fromother offer distributors 1592.

Offer Parameter Optimizer

Offer distribution system 1550 may comprise an offer parameter optimizer1583 that proposes parameters for possible offers that offer providers1595 may wish to provide. For example, in an embodiment, an offerprovider 1595 may log into offer definition interface 1584 and select anoption to create a new offer. As the offer provider enters variousparameters of the offer, such as identifiers of items eligible for theoffer, the offer definition interface may query the offer parameteroptimizer 1583 for suggested or default parameters based on what theoffer provider has entered so far. For example, offer parameteroptimizer 1583 may suggest a discount amount, regions in which the offershould be provided, a timeframe for the discount, an amount tocompensate the offer distributor for offer impressions or activations,and so forth.

Offer parameter optimizer 1583 may analyze a variety of data sources tosuggest offer parameters, including without limitation the transactiondata store 1545, the consumer data store 1558, historical offer data1585, offer activation and redemption tracking logs 1588, web histories,and so forth.

In one embodiment, offer parameter optimizer 1583 may receive, and mayanalyze, contextual transaction data received directly or indirectlyfrom a retailer or other terminal that is facilitating a consumerelectronic transaction, such as the contextual transaction data 1345discussed in connection with the embodiment of FIG. 13A. In variousembodiments, contextual transaction data may include any of a variety ofinformation related to one or more consumer transactions conductedwithin a facility owned, controlled or operated by a retailer, includingwithout limitation basket-level transaction details such as universalproduct codes and quantities purchased, total number of items purchased,transaction amounts, payment details (e.g., a credit card number, apayment identifier, a secure payment hash key), information about a dataprocessing system, logic module or facility where the transaction takesplace (e.g., terminal 1340 or store 1330), time, date, offers appliedduring the transactions, information relating to the customer conductingthe transaction (e.g., a name, a phone number, a pin number, a password,a code, a loyalty card number, other biometric or personalidentification data, etc.), RFID data, a device identifier, items thatwere purchased in a previous or concurrent transaction, a transactionnumber, and so forth.

In one embodiment, offer parameter optimizer 1583 may receive, and mayanalyze, historical transaction records retrieved from a memory orreceived from a remote retailer or other entity, such as the historicaltransaction records discussed in connection with the embodiment of FIG.13A. Historical transaction records may include various classes ofinformation that relate to users, transactions, vendors, paymentprocessing, and any other aspects of electronic or physical commerce. Asan example, historical transaction records may be, or may includecontextual transaction data that was generated in connection withprevious transactions. In various embodiments, historical transactionrecords may include any of a variety of information related to one ormore past consumer transactions conducted within a facility owned,controlled or operated by a retailer, including without limitationbasket-level transaction details such as universal product codes andquantities purchased, total number of items purchased, transactionamounts, payment details (e.g., a credit card number, a paymentidentifier, a secure payment hash key), information about a dataprocessing system, logic module or facility where the transaction takesplace (e.g., terminal 1340 or store 1330), time, date, offers appliedduring the transactions, information relating to the customer whoconducted the transaction (e.g., a name, a phone number, a pin number, apassword, a code, a loyalty card number, other biometric or personalidentification data, etc.), RFID data, a device identifier, items thatwere purchased in a previous, concurrent or subsequent transaction, atransaction number, and so forth.

Offer parameter optimizer 1583 may be configured to determine orproject, based on historical transaction records from these sources, animpact of an offer on sales of certain items, redemption rates, profitper impression (e.g. based on transaction data, click-through rate,offer tracking, etc.), profit margins, and other metrics of interest tothe offer provider 1595. Offer parameter optimizer 1583 may use theseprojections to propose offer parameters to the offer provider 1595.Offer parameter optimizer 1583 may further or instead allow the offerprovider 1595 to visualize the projected impact of the offer on thesemetrics as the offer provider 1595 defines or changes the offerparameters. For example, the offer definition interface 1584 may includegraphs, charts, or tables illustrating the projected impacts. In anembodiment, the offer provider 1595 may instruct the offer definitioninterface 1584 to define an offer that optimizes for certain projectedmetric(s) or that even meets defined projected metric value(s). Theoffer definition interface 1584 in turn requests that the offerparameter optimizer 1583 define an offer that is best performing withrespect to the metric(s) and/or closest to meeting the projected metricvalue(s).

In an embodiment, offer parameter optimizer 1583 may proactively suggestnew offers that one or more of the offer providers 1595 may wish tocreate. To achieve this, offer parameter optimizer 1583 may processvarious historical transaction records, may evaluate various offer dataassociated with the one or more of the offer providers 1595, and/or maytake into consideration contextual transaction data received fromconsumer transactions that are taking place simultaneously,substantially simultaneously, or took place recently.

Examples of offer data that may be used to suggest an offer include anoffer provider identity, a historical or projected impact of the offeron sales of an item, a historical or projected offer redemption rate, ahistorical or projected profit per offer impression, a historical orprojected profit margin, a historical trend in offers made available bythe offer provider, and so on. In various embodiments, offer data mayinclude, may be, or may be included in the data stored in offer data1585.

As another example of offer data that may be used to suggest an offer,offer parameter optimizer 1583 may recognize a trend in how often offerprovider 1595 creates an offer for a certain category of items. Aroundthe time frame when the offer provider 1595 is next expected to createan offer for that category of items, offer parameter optimizer 1595 maysuggest to offer provider 1595 a new offer with parameters based on theprevious offers. As another example, offer parameter optimizer 1583 mayperiodically analyze the sales of items sold by an offer provider 1595to identify parameters for possible offers that would be projected toincrease sales and/or profits for the offer provider 1595. Theprojections may, for instance, be based on similar offers for similarcategories of items sold by any of offer providers 1595.

New offer(s) may be suggested using a variety of mechanisms, includingan email or an alert when the offer provider 1595 logs into the offerdefinition interface 1584. The offer provider may then create the offersimply by clicking on a button that accepts the suggestion. In anembodiment, the offer parameter optimizer 1583 may be configured toautomatically create new offers for an offer provider 1595 without theoffer provider 1595 explicitly being involved in generating the offer.For example, an offer provider 1595 may have provided standinginstructions to create a new offer each month for a particular item, andpre-authorized the offer distribution system 1550 to dynamicallydetermine certain parameters, within certain constraints. In anembodiment, the offer provider 1595 will be notified of automaticallycreated offers in advance of the offer start date, and thus have anopportunity to remove or modify the offer before it can be distributedby offer distribution system 1550.

2.5. Offer Targeting Architecture

FIG. 16 illustrates an example system 1600 for distributing targetedoffers, according to an embodiment. System 1600 is but one example of asystem for targeting offers. Other systems may include fewer ordifferent components in varying arrangements. In an embodiment, othertechniques described herein may be practiced with any suitable offertargeting system. In an embodiment, system 1600 is similar to systems1300, 1400, and/or 1500. In other embodiments, system 1600 is differentfrom systems 1300, 1400, and/or 1500.

System 1600 comprises an offer distribution system 1650 operated by anoffer distributor. Offer distribution system 1650, which may similar toor different from offer distribution system 1550, is a system of one ormore data processing systems that, among other aspects, deliverinformation about targeted offers 1652 to a variety of endpoints1610-1616. Each targeted offer 1652 has been matched to a specificconsumer or group of consumers in response to the detection of certainevents 1651 a-c that have been correlated to the specific consumer ofgroup of consumers. In an embodiment, events 1651 a-c may be anyarbitrary type of event. The ability to identify a consumer's contextbased on these arbitrary events renders offer distribution system 1650more flexible in targeting offers than other targeting systems, whichare limited to few targeted context types.

Endpoints 1610-1616 are examples of some of a variety of data processingsystems or logic modules that a consumer may use to interact with offerdistribution system 1650. Endpoints 1610-1616 may include retail devices1610 such as terminals 1340 or online stores 1332, devices executingshopping list management applications 1611 or shopping list managementservers, smartphones or other consumer devices 1305 that execute mobileapplications 1612, application servers 1613 that execute websites suchas social networks or media portals, payment servers 1614 such as thoseof payment system 1450, transaction aggregation devices 1615 such asthose of transaction aggregation system 1350, and/or devices within anyof a variety of other systems 1616 operated by other entities.

Events 1651 may be data structures that represent any of a variety ofconsumer actions observed by these devices. Events 1651 may reflect, forexample, item purchases, transactions, offer redemptions, offeractivations, offer viewing, web requests, shopping list additions,shopping list removals, application access, media consumption, locationtracks, messages, social media sharing activities or “likes”, and soforth. Each event 1651 may include, among other elements, consumeridentifying information such as email addresses or PANs, actionidentifying information such as an action type or request metadata,contextual information such as a location or time or date, and/or otherdata as relevant. In one embodiment, events 1651 may be, or may includehistorical transaction records retrieved from a memory or received froma remote retailer or other entity, such as the historical transactionrecords discussed in connection with the embodiments of FIG. 13A or FIG.15. In one embodiment, events 1651 may be, or may include contextualtransaction data retrieved from a memory or received from a remoteretailer or other entity, such as the contextual transaction data 1345discussed in connection with the embodiments of FIG. 13A or FIG. 15.

Events 1651 from endpoints 1610-1616 may be communicated as raw events1651 a to event handlers 1661 of offer distribution system 1650. Rawevents 1651 a may be proactively pushed to event handlers 1661, polledfrom endpoints 1610-1616, and are data mined from endpoints 1610-1616.Raw events 1651 a may be received in real-time or in periodic batches.Raw events 1651 a may not necessarily have been formulated by thesending endpoint 1610-1616 as an event construct. Instead, events 1651 amay be web requests or other routine messages from endpoints 1610-1616that event handlers 1661 interpret as events.

Event handlers 1661 include one or more server components, each of whichreacts to certain types of raw events 1651 a. For example, eventhandlers 1661 may include any or all of web servers that react to webrequests, web log analyzers that react to web logs, messaging serversthat react to request to send messages, receipt servers, offer servers,advertisement servers, transaction aggregation systems, payment servers,and so forth. In addition to responding to their respective types of rawevents 1651 a, event handlers 1661 may store event records in event logs1656. Event handlers 1661 may include normalization components fortranslating raw events 1651 a into normalized constructs, aggregatorsfor grouping certain types of events together into an aggregated eventcomprising multiple raw events 1651 a, and an event gateway for relayingevents to other appropriate event handlers 1661.

In one embodiment, event handlers send an optionally filtered set ofevents 1651 b to an event contextualizer 1682. Event contextualizer 1682may generate contextualized events 1651 c that include both datadescribing one or more consumer actions and data describing a context inwhich those one or more actions occurred. The context may be derived, inpart, by correlating a consumer entity to the event using consumer data1658. In an embodiment, offer distribution system 1650 further includesa consumer context engine 1681 that generates consumer context data 1657based on filtered events 1651 b. For example, consumer context data 1657may record a current consumer's location, recent shopping list items,recent web behaviors, and so forth. Event contextualizer 1682 mayutilize the consumer context data 1657 (or communicate with consumercontext engine 1681 to obtain suitable context data) when generatingcontextualized events 1651 c.

In one embodiment, offer distribution system 1650 further includes anoffer definition interface component 1684, also denoted an offerdefinition interface, which may be similar to or the same as offerdefinition interface component 1584. Via offer definition interface1684, offer providers 1695 may generate targeted offers that are storedin targeted offer data store 1685, which may be the same as offer datastore 1385 or 1585. These targeted offers are associated by offerassociations with targets defined in target definition data 1686. Atarget may be a data construct that defines a context and/or an event inresponse to which an offer provider wishes to display an offer.

Offer providers may define their own targets using offer definitioninterface 1684, and/or may be assisted in defining targets based on anoptional target optimizer 1683. Target optimizer 1683, in similar mannerto offer parameter optimizer 1583, analyzes a variety of data sources tosuggest targets that may be of interest to offer provider 1695. Thesedata sources may include, for example, event logs 1656 (includingtransaction data) and consumer context data 1657.

In one embodiment, an offer provider, such as offer providers 1695, andan offer distributor, such as an offer distributor operating the offerdistribution system 1650, may engage in an express or implied commercialnegotiation with respect to the selection and distribution of offers.For example, the offer distribution may have the option to choose todistribute various offers provided by an offer provider and/or may beable to choose to distribute various offers provided by different offerproviders. In such cases, the offer distributor may compute differentmetrics for the various offers available for distribution, and thenbased on those metrics, may select one or more offers for distribution.

In one embodiment, an offer distributor may analyze various contextualtransaction data, historical transaction records and/or offer dataassociated with two or more offers, and may decide which of those offersto distribute. In one embodiment, an offer distributor receives a set ofoffer data associated with each offer, such as, for example, an offerprovider identity, a historical or projected impact of the offer onsales of an item, a historical or projected offer redemption rate, ahistorical or projected profit per offer impression, a historical orprojected profit margin, a historical or projected offer volume (e.g.,the total number of offer activations, offer impressions, offerredemptions and/or products sold), a historical or projected offer yield(e.g., a total profit figure associated with an offer after taking intoaccount the total number of sold products corresponding to that offer,offer activations, offer impressions and/or offer redemptions), ahistorical trend in offers made available by the offer provider, ahistorical or projected profit margin for the offer distributor and/orfor the offer provider, a historical or projected impact of the offer onother offers, a historical or projected impact of the offer on consumerbehavior, etc.

In one embodiment, one or more offer providers may choose to incentivizethe offer distributor to influence the offer distributor's selection ofoffers to be distributed. For example, an offer provider may seek toimprove a metric computed by an offer distributor for a particularoffer, and therefore make it more probable that the offer providerchooses that particular offer for distribution. For instance, an offerprovider may pay the offer distributor more to distribute one or moreparticular offers.

In one embodiment, one or more other offer distributors may influence aparticular offer distributor's selection of offers for distribution. Forexample, a particular offer distributor may receive commercialincentives from other offer distributors to distribute or not distributea particular offer, or to distribute a particular offer through aspecific distribution channel (e.g., through another offer distributor,to a particular retailer, etc.).

In an embodiment, offer definition interface 1684 further allows anoffer provider 1695 to specify a “bid” amount that the offer provider1695 is willing to compensate the offer distributor for presenting anoffer for a particular target. Target optimizer 1683 may analyzecontextual transaction data, historical transaction records, offer data(such as the offer data discussed in connection with the embodiment ofFIG. 15), and any other transaction data or offer tracking data tosuggest an optimal bid for the targeted offer. For example, if an offerprovider 1695 sees that an offer is not being presented frequently bythe various algorithms of offer distribution system 1650, the offerprovider 1695 may request that the target optimizer 1683 run various“what-if” scenarios to determine how much more frequently an offer wouldbe presented with different bids. In one embodiment, the targetoptimizer 1683 may predict how much more profitable the offer would beat each corresponding bid. In some embodiments, a similar system may beutilized for assisting the offer provider in determining a suitablecompensation amount for non-targeted offers presented by arecommendation engine as described herein.

Offer distribution system 1650 further includes a target offer selectioncomponent 1680, which may be an offer server 1380 or 1580. In fact,target offer selection component 1680 may be an event handler 1661.Target offer selection component 1680 compares contextualized events1651 c to target definitions 1686. It then provides to endpoints1610-1616 targeted offers 1652 from data store 1685 that are associatedwith matching targets. In some target offer selection component 1680 mayselect all offers that match. In other embodiments, target offerselection component 1680 rank the matching offers by any suitable means,and only present the highest ranked offer(s). In an embodiment, an exactmatch is required. In other embodiments, offers may be ranked by howclosely they match a target.

Targeted offers 1652 may be provided to any or all of endpoints1610-1616. When triggering event 1651 is a direct request for offersfrom a particular end point, targeted offers 1652 may be provided inresponse to the direct request. Targeted offers 1652 may also be“pushed” to end points 1610-1616 in response to various triggeringevents 1651 without endpoints 1610-1616 having directly requested anoffer.

In an embodiment, some or all target definitions are agnostic as toevents, and merely reflect consumer contexts. Hence, any event 1651 willmatch the target as long as the context of the event matches the contextdefined in the target. In other embodiments, offer distribution systemmay not feature event contextualizer 1682 at all.

In an embodiment, some or all of the event records stored in event logs1656 may be correlated to consumer entities, aggregated, and/orotherwise contextualized.

2.6. Offer Recommendation Architecture

FIG. 17 illustrates an example system 1700 for recommending offers,according to an embodiment. System 1700 is but one example of a systemfor recommending offers. Other systems may include fewer or differentcomponents in varying arrangements. In an embodiment, other techniquesdescribed herein may be practiced with any suitable offer targetingsystem. In an embodiment, system 1700 is the same system as system 1300,1400, 1500, and/or 1600. In other embodiments, system 1700 is differentfrom systems 1300, 1400, 1500, and/or 1600.

Example system 1700 comprises an offer distribution system 1750, similarto other offer distributions described herein. A signal processor 1771inputs data from a variety of sources, which, without limitation, mayinclude any or all of transaction data 1755, shopping list data 1756,consumer data 1758, offer data 1785, offer tracking data 1788, orproduct data 1754. Shopping list data 1756 may be, for example, currentor historical lists of items that a consumer has saved using a shoppinglist server. Signal processor 1771 generates signals 1751 based on thesedata sources. The signals 1751 and associated offer data 1752 are fed toa scoring engine 1772.

Scoring engine 1772 executes one or more scoring functions 1775. Forexample one type of scoring function 1775 utilizes the input signals togenerate various association score(s) between various context items andthe offer being scored. The association score(s) are then used, alongwith various weights, to generate offer score(s) 1776 for each offer.These scoring functions 1775 may have been derived in full or in partmanually, or may have been learned by a learning component 1774 usingany suitable machine learning techniques. The scoring functions may beoptimized for different objective functions, also referred to herein askey performance indexes (KPIs). Different objective functions may besuitable for different recommendation contexts. Hence, different scoringfunctions 1775 may be executed by scoring engine 1772 for differentrecommendation contexts.

The scores may optionally be weighted by a contextual weightingcomponent 1781. Contextual weighting component 1781 may assign differentweights depending on the recommendation context. The offer scores 1776are used to compute universal scores and ranked offer sets 1778 a forthe offers by universal scoring and ranking component 1777. Optionally,the ranked offers 1778 a may be filtered by an offer filtering component1779, which executes business rules. The optionally filtered set ofranked offers 1778 b is then fed to a recommended offer interface 1780,which may be the same as, for instance, offer servers 1380 and 1580.Recommended offer interface 1780 provides some or all of theserecommended offers as recommended offer set 1778 c to consumer devices1705. Recommended offer set 1778 c may be provided directly viainterface 1780, or indirectly by one or more intermediate websites orother servers.

While targeted offers and recommended offers are described in the aboveexamples as being delivered separately to consumer devices, offerdistribution system 1750 may also be modified to include targeted offersin a ranked offer set 1778 a. In such an offer set, a universal score isassigned to each targeted offer based on factors such as an offerprovider's bid and so forth. The targeted offer(s) may then be rankedalong with the recommended offers. In an embodiment, the highest rankedtargeted offer(s) are always presented first (i.e. assigned anarbitrarily high universal score). However, this is not the case inother embodiments.

2.7. Integrated Recommendation and Targeting Architecture

FIG. 31 illustrates a system 3100 for integrating offer recommendationsand targeted offers, according to an embodiment. System 3100 is but oneexample of a system for integrating offer recommendations and targetedoffers. Other systems may include additional or fewer elements inpotentially varying arrangements.

System 3100 comprises endpoints 3110, including smartphones, personalcomputers, retailer terminals, ATMs, microsites, and other endpointsdescribed herein. Endpoints 3110 send requests 3115 to an offerdistribution interface 3120. For example, a suitable offer distributioninterface 3120 may be provided by an offer server or receipt server.Context data 3125 and 3126, such as credentials, associated items,location data, and other contextual data described herein, are locatedin or derived from data associated with the requests 3115. Context data3125 and 3126 may be overlapping or even the same sets of data, orcontext data 3125 and 3126 may be different sets of data selectedspecifically for making recommendations and for targeting offers,respectively.

System 3100 comprises a recommendation engine 3130 to which context data3125 is sent. Based at least on context data 3125 that can be resolvedto a particular consumer entity, which may or may not span multiplerequests 3115, the recommendation engine 3130 derives various signalsand/or weights for various ranking algorithms. For example, context data3125 indicating historical trends for a consumer may be used to generateone signal, while a recent set of context data for the consumer may beused to generate another signal. The recommendation engine 3130 appliesthe ranking algorithms to a repository of offer data 3150 to select setsof recommended offers 3155 from a plurality of offers described in arepository of offer data 3150 in system 3100.

System 3100 also comprises a targeting engine 3140 to which context data3126 is sent. The offer data 3150 includes data associating certainoffers with certain predefined target contexts. The targeting engine3140 determines whether context data that can be resolved to aparticular consumer entity matches any of the target contexts, usingtechniques such as described herein. When any of the target contexts arematched, one or more offers associated with the matched targetcontext(s) are selected from the plurality of offers described in theoffer data 3150. The selected offers are targeted offers 3156.

Recommended offers 3155 and targeted offers 3156 are identified to theoffer distribution interface 3120. Based thereon, the offer distributioninterface 3120 may then generate recommended offer information 3165,describing some or all recommended offers in a particular set ofrecommended offers 3155, and send it to endpoints 3110 associated withthe context data 3125 based upon which the sets of recommended offers3155 were respectively chosen. The offer distribution interface 3120 mayalso generate targeted offer information 3165, describing some or alltargeted offers in a particular set of targeted offers 3156, and send itto endpoints 3110 associated with the context data 3126 based upon whichthe sets of targeted offers 3156 were respectively chosen. Therecommended offer information 3165 and targeted offer information 3166may be presented in any suitable manner, including those described inother sections.

The recommended offer information 3165 and targeted offer information3166 may be sent in response to particular requests 3115 based uponwhich the recommended offer information 3165 and targeted offerinformation 3166 were generated, or at times independent of suchparticular requests 3115. Not all of requests 3115 are used to generaterecommended offer information 3165 and targeted offer information 3166.For example, some requests 3115 may not match any target context, andmay not be associated with an opportunity to make recommendations.

In an embodiment, recommended offer information 3165 and targeted offerinformation 3166 are sent separately to endpoints 3110, at potentiallydifferent times relative to each other. For example, recommended offerinformation 3165 may be sent in a web page responsive to a particularrequest 3115, while targeted offer information 3166 may be sent in anemail or other message whenever targeted offers 3156 are identifiedbased on event logs. In an embodiment, some targeted offer information3166 and recommended offer information 3165 are sent to endpoints 3110at the same time, within a web page or application interface. Thetargeted offer information 3166 and recommended offer information 3165may be displayed within different sections of the web page. Or, thetargeted offer information 3166 and recommended offer information 3165may be intermingled in a single listing. For example, a targeted offer3156 may always be the first offer in a list that is otherwise comprisedof recommendations 3155. Or scoring techniques may be utilized to sort amerged list of recommended offers 3155 and targeted offers 3156.

2.8. Miscellaneous

For simplicity, various steps are described herein as being performed byentities such as the “retailer,” “payment provider,” “offerdistributor,” and so forth. However, many of these steps are in factperformed by data processing systems, such as described above, that havebeen configured by or on behalf of the entities said to perform thesteps. The exact configurations of these data processing systems mayvary depending on a number of factors known in the art. Unless otherwisestated, the techniques described herein are thus not limited to anyparticular configurations of these data processing systems.

3.0. Functional Overview

3.1. Cross-Retailer Transactional Data

As described in other sections, multiple different retailers maycommunicate transaction data to a coordinating computer, such as aserver operated by an offer provider, offer distributor, paymentprovider, shopping incentive provider, or dedicated receipt provider.This data may be collected in consumer purchase histories, which, asexplained herein, may be used for purposes ranging from creating a“digital locker” of consumer receipts to selecting offers to present tothe consumer. In some embodiments, transaction data from multipleretailers, or cross-retailer transactional data, can thus be utilized toprovide offers to consumers. For example, in an embodiment, offerselection can be based on both purchase history and a retailer identity.In such cases, offer selection may or may not be filtered to just thoseoffers that pertain to a given retailer. In another describedembodiment, only a purchase history is utilized for offer selection, andthus offer selection is necessarily based on transaction dataindiscriminately of the identity of the retailer that provided thetransaction data. In yet other embodiments, cross-retailer transactionaldata may be used to various degrees—for instance, transactional datafrom certain retailers may be weighted more strongly based on theconsumer's location.

Various specific implementations involving the provision of offers basedpartly or entirely on cross-retailer transactional data are described inthis section. However, the use of cross-retailer transactional data isnot limited to these specific implementations, but rather is alsocompatible with the other systems and other techniques in addition tothose described herein.

FIG. 12 illustrates a flow 1200 for providing offers based ontransactional data gathered from multiple different retailers, accordingto an embodiment.

Block 1210 comprises receiving, from multiple retailers, transactiondata. The transaction data comprises transaction logs from theretailers, each log recording details of a different transaction at acorresponding one of the retailers. Each transaction log comprisesbasket-level information, including one or more item identifiers foritems purchased in the transaction. The items may include productsand/or services. Each transaction log further comprises one or moreconsumer identifiers, such as a loyalty card identifier, credit cardnumber, account number, name, phone number, email address, IP address,mobile device identifier, and so forth. Each transaction log optionallycomprises other transactional informational, including a time, date,retailer identifier, store identifier, geo-location data, and so forth.Block 1210 may be performed, for instance, by a coordinating server asdescribed in other sections, operated as a service for the multipleretailers by a third-party service provider.

Block 1220 comprises optionally normalizing the item identifiers.Different retailers may utilize different proprietary identificationschemes to identify various items. For example, one retailer may referto a specific type of apple as “item A108” while another retailer mayrefer the specific type of apple as “item 78923.” The coordinatingserver may resolve the discrepancy by normalizing both identifiers to acanonical representation such as “item APPLE10923.” The coordinatingserver may maintain item mapping data that normalizes proprietary itemidentifiers for specific retailers to canonical item identifiers. Suchitem mapping data may be provided by each specific retailer, and/orproduced by an analysis of the retailer's inventory.

In an embodiment, some or all of the item identifiers already conform toa common identification scheme. For example, the majority of itemidentifiers may all be Uniform Product Codes (UPCs). Thus, block 1220 isnot necessary. In an embodiment, even though some items may haveinconsistent identifiers at certain retailers, most items are identifiedby a consistent identifier at most retailers. Only the items havinginconsistent identifiers need be normalized in block 1220. Or, block1220 may be skipped altogether, and items with inconsistent identifiersare treated as different items for the purposes of the describedtechniques.

In an embodiment, block 1220 may be part of a larger transaction lognormalization process. That is, transaction logs themselves may conformto different formats depending on the retailer. The coordinating servermay include one or more transaction log normalization components, towhich transaction logs are submitted as they are received. As a resultof normalization, the transaction logs all conform to a common format.However, in an embodiment, retailers format transaction logs in thecommon format before sending the transaction logs to the retailer, andthus the logs do not require normalization.

Block 1230 comprises associating the transaction logs with consumerentities in a consumer database. The consumer database comprises aplurality of consumer entity objects, each corresponding to a differentconsumer entity. Each consumer entity is mapped to one or morecredentials. The credentials may include, without limitation, uniqueidentifiers or unique combinations of identifiers, passwords, contactinformation, and/or demographic data. The credentials belonging to aspecific consumer entity may have been provided by a consumer, forexample, during an account registration process with an offerdistributor or retailer. Alternatively or additionally, the credentialsbelonging to a consumer entity may have been learned from thetransaction logs over time. Credentials may also be submitted from avariety of other sources.

Because many of the consumer credentials provided during a transactionmay not in fact uniquely or even accurately identify real-worldconsumers, consumer entities may or may not actually correspond toreal-world consumers. For example, several different consumers in ahousehold may share loyalty card information, and thus a consumer entitybased solely on loyalty card information would correspond to multiplereal-world consumers. As another example, a phone number given during acheckout process may have once belonged to a different consumer with adifferent transaction history than the consumer that is currently usingthe phone number. A consumer entity based solely on phone numbers thuswould not accurately reflect the real-world consumer that is providingthe phone number.

In some embodiments, the techniques practiced herein nonetheless producesufficient results by making assumptions that each of certain types ofcredentials, such as credit card identifiers, loyalty card identifiers,or phone numbers, uniquely correspond to a consumer entity. Thus, block1230 in these embodiments simply comprises looking up consumer entitiesby querying the database using one or more consumer identifiers providedin each transaction.

In other embodiments, various data-mining techniques may be utilized torefine the consumer database to better reflect real-world consumers.Thus, for example, different consumer entities modeling differentmembers of a household may be associated with the same loyalty cardidentifier. In such environments, various pattern matching and/ormachine learning mechanisms may be used to compute likelihoods thatcertain transaction logs belong to certain consumer entities. Consumerentities are then matched to transaction logs based on the computedlikelihoods.

Once the consumer entity that is associated with a transaction log isidentified, a unique consumer entity identifier is then mapped to thecorrelated transaction log and/or a unique transaction identifier ismapped to the associated consumer entity. Correlations betweentransaction logs and consumer entities may be reevaluated over time, ifnecessary, to reflect any more accurate information about the consumerentities that may be received.

Block 1240 comprises storing the transaction logs in a data store,thereby forming transaction/purchase histories for a plurality ofdifferent consumer entities across a plurality of different retailers.Optionally, block 1240 comprises aggregating data from the transactionlogs into summary information that is stored for quicker analysis. Forexample, such summary information might indicate, without limitation,the number of times a consumer has purchased an item, a last time theconsumer purchased the item, purchase patterns for the consumer withrespect to the item over time, and correlations between the consumer'spurchase of an item with the consumer's purchase(s) of other item(s).The transaction data store may be used for a variety of purposesdescribed herein, including performance of the subsequent steps.

In an embodiment, block 1210 to block 1240 inclusive are performed inreal time with respect to each transaction. In this context, “real time”means in general that, as soon as a transaction is performed, theretailer uploads a transaction log to the coordinating server, whichthen performs blocks 1220 to 1240; however, “real time” performance doesnot require an instantaneous or concurrent response and some time lagmay occur. In an embodiment, various stages of blocks 1210-1240 areperformed asynchronously relative to transactions. For example, aretailer may batch transaction logs from multiple transactions, andupload those transactions to the coordinating server periodically. Thecoordinating server may also, in some embodiments, comprise variouscomponents that perform blocks 1220-1240 asynchronously with respect toeach other, with unprocessed transaction logs being stored in variouspools or caches until a next component is ready to process thetransaction logs.

Block 1250 comprises receiving a request for one or more offers. Therequest may be received at an offer server that has access to thetransaction data store, which may or may not be the same as thecoordinating server that performed blocks 1210 to 1240. The request mayoriginate from any suitable source, including end-user based clientapplications communicating over a wide area network and/or other serverscommunicating via any type of network. For example, as described inother sections, the request may originate from a web-based or mobilereceipt-viewing application. Or, the request may originate from a couponapplication or a shopping list management application executing on amobile device. Or, the request may originate from a server that iscommunicating with a client device operated by a consumer. Or, as yetanother example, the request may originate from an ad platform.

Block 1260 comprises matching the request to a consumer entity, based oncontext information in and/or associated with the request. The requestmay, in some embodiments, comprise data that explicitly specifies theconsumer entity associated with the request. For example, if eachconsumer entity is presumed to have a separate loyalty card identifier,the request may simply specify a loyalty card identifier. Or if therequest originates from an application that requires the consumer tologin to an account that is uniquely associated with a consumer entity,the request may simply specify account credentials. In otherembodiments, the request includes various context signals, includingconsumer identifiers, geolocation data, device identifiers, and soforth. The request may be matched to a consumer entity in similar mannerto the likelihood-based consumer entity matching technique describedwith respect to block 1230. In yet other embodiments, context signalsfor consumer entity matching are mined from data outside of the request,such as geolocation data and/or items listed in shopping list datapreviously uploaded from the device issuing the request.

Block 1270 comprises identifying one or more offers responsive to therequest. The identifying is based on transaction data, from one ormultiple retailers, that has been mapped to the matched consumer entityin the transaction data store. A variety of techniques for utilizing thecross-retailer transactional data are possible. For example, thecross-retailer transactional data may be mined for purchase patterns. Ifa purchase pattern reveals that a consumer entity frequently buys milkon Tuesday, for instance, and the request is received on a Tuesday, anoffer associated with milk may be offered to the consumer. The use ofcross-retailer transactional data may allow for better patternrecognition than would be conventionally possible. For example, if theconsumer frequently buys milk from different retailers on Tuesday, itwould not have been apparent to any particular one of those retailers,or to any single producer of milk, that a pattern existed for theconsumer.

As another example, recent transaction logs can be utilized to identifyitems that are not likely to be purchased by the consumer in the nearfuture. For example, if the consumer does proceed to buy milk, and thensends another request for an offer, offers for milk may be suppressed.Similarly, recent transaction logs may be used to identify complimentaryitems in which the consumer may be interested. For example, if theconsumer has recently bought milk, the offer server may determine toprovide the consumer with an offer for cookies. Complimentary items maybe suggested based on correlations identified in transaction logsassociated with the current consumer entity, similar consumer entities,or even an entire consumer base as a whole. Complimentary items may alsobe specified by offer providers or retailers.

The use of cross-retailer transactional data may increase the timelinessof offers. For example, a retailer A would not conventionally have knownthat a consumer just bought milk at retailer B, and thus could haveinadvertently provided the consumer with a milk offer that would be ofno interest to the consumer. By contrast, by participating in the systemdescribed herein, the offer server may provide retailer A with anindication of which offer(s) would be of most use to a particularconsumer entity. Retailer A may then proceed to provide the identifiedoffer(s) to the consumer in, for instance, a receipt, via anoffer-distributing web-based or mobile application, or via any otheroffer distribution mechanism. Similarly, a third-party distributor ofoffers and other offers to end-users may leverage the techniquesdescribed herein to increase the value of its services to both RetailerA and Retailer B, thus increasing the amount the distributor is able tocharge for its services.

In some embodiments, other suitable factors described elsewhere in thisdisclosure may be utilized in conjunction with the cross-retailertransactional data to identify offers responsive to a request, includingshopping list data, offer redemption history, consumer preferences, andso forth.

Block 1280 comprises causing the identified offer(s) to be presented toa consumer. The offers are often presented at a client device in aninterface displayed by a web-based or mobile application. The interfacemay be a receipt-viewing interface, as described herein. Or, theinterface may be any other suitable interface, including withoutlimitation a coupon-clipping web page on a desktop computer, a shoppinglist management application on a mobile phone, a contextual ad-deliveryinterface, a self-checkout interface on a website or on an in-storekiosk, an automated teller interface on an ATM, and so forth. The offerserver performs block 1280 at least partly by sending data describingthe identified offer to a client device or web server.

In at least one embodiment, the offers presented to a consumer, whetheron a receipt or in any other form, may have been selected based ontransaction data from multiple retailers. In an embodiment, at least oneoffer that is presented on a receipt was selected based on transactiondata from a retailer other than the retailer that engaged in thetransaction for which the receipt was generated.

Flow 1200 is but one example technique for providing offers based oncross-retailer transactional data. Other techniques may involve fewer,additional, and/or different elements in potentially varyingarrangements.

3.2. Providing Offers

A variety of techniques for providing offers and/or coupons basedthereon are described in, for example, U.S. application Ser. No.12/878,231, U.S. application Ser. No. 12/896,206, and U.S. applicationSer. No. 13/396,553, the contents of each of which are herebyincorporated by reference for all purposes, as if set forth in theirentirely herein. Example techniques for providing offers are furtherdescribed below.

General Flow

FIG. 18 is a process flow 1800 illustrating a method of providing offersat a consumer-operated device, such as consumer device 1305, accordingto an embodiment.

Block 1810 comprises the consumer initiating interaction with a deviceby engaging in a task that triggers execution of particular applicationfunctionality, such as launching a mobile application, visiting a webpage, pressing a button on a kiosk, swiping a phone in front of an NFCreader, swiping a card, entering the vicinity of one or more sensorsconfigured to detect the presence of the consumer device via informationshared in signals transmitted from the consumer device, or entering inthe vicinity of one or more biometric or facial recognition sensors fordetecting the consumer's presence.

Block 1820 comprises the consumer providing identifying information tothe device. In an embodiment, block 1820 comprises logging in to thedevice by presenting credentials such as a consumer identifier, emailaddress, phone number, pin number, password, biometric data, an oralpassphrase, and so forth. The consumer information may be collectedexplicitly from consumer input, derived from consumer input based onrecords associated with that input, or collected from various sensorswithout the consumer's explicit input. The identifying information maybe provided at any time relative to the remaining blocks of flow 1800,including immediately after block 1810, after other blocks of flow 1800,or at some time much previous to block 1820, as in the case asremembered credential information. Block 1810 may in fact be the same asblock 1820.

Block 1830 optionally comprises the device collecting additionalcontextual information, including without limitation: the device'scurrent location; information about the device's current interactionswith the consumer, such as information currently being displayed by thedevice or items currently being purchased by the consumer; informationabout any other recent interactions between the device and the consumer,such as applications the consumer may have been using at the device justprior to block 1810; or sensor data collected from some or all of thedevice's sensors, including radios, cameras, and/or microphones.

Block 1840 comprises the device sending the identifying information and,if collected, the additional contextual information to an offer server,such as offer server 1380. All of the data may be sent at the same time,or the data may be sent separately, as it is collected. The device maybe connected to the offer server via any suitable means, including viaintermediary systems, such as retail data centers or ad platforms, whichmay or may not further process the data before sending the data to anoffer server. The data may, in some cases, be sent indirectly to theoffer server. For example, some or all of the data may be stored asrecords in a database of recent state information for consumer entities,from which the offer server may be configured to retrieve the data.

Block 1850 comprises the offer server identifying a consumer entity thatmost likely corresponds to the consumer. For example, the offer servermay attempt to match various aspects of the consumer identifyinginformation, or even the contextual information, to consumer entityrecords stored in a consumer data store such as data store 1358. Varioustechniques for resolving consumer entities are described herein. Theoffer server may be configured to only match a consumer entity to theconsumer if a matching score surpasses a certain threshold. If nomatching score surpasses a threshold, the consumer may be asked toprovide further identifying information, flow 1800 may terminate, or theconsumer may be provided an offer using a more general algorithm thatdoes not rely upon consumer specific data.

Block 1860 comprises the offer server identifying one or more offers toprovide the resolved consumer entity, using any of the recommendation ortargeting techniques described herein. Block 1870 comprises the offerserver sending offer data describing the identified offer(s) to thedevice, as described in other sections.

Block 1880 comprises the device displaying the offer data to theconsumer. In some embodiments, the device may reformat and/orpre-process the offer data. For example, the device may display theoffer data in a series of navigable screens. The device may display theoffer information within a window that interrupts the consumer'sworkflow with the application function of block 1810, or in a separatewindow or display that does not interrupt the consumer's workflow. In anembodiment, the offer information is displayed only while the device isprocessing the consumer's main request so as not to interfere too muchwith the consumer's workflow. For example, the offer information mayonly be displayed while the device is processing payment of atransaction. The offer information disappears within a certain time ofconcluding the processing.

In some embodiments, the display of the offer data will optionallyinclude interface controls for the consumer to express an interest inobtaining a coupon for the offer or in otherwise activating the offerfor possible future redemption. Block 1885, which is also optional,accordingly comprises receiving a request from the consumer to activatethe offer. In an embodiment, the request, or a lack of the request, isimplied after a predefined timeout period, such as within a certain timeafter the device has finished processing the consumer's main request.

Block 1890 comprises the offer server “activating” the offer. In anembodiment, block 1890 may more specifically comprise sending coupondata to the device so that the device may print a coupon. For example,if the device is an ATM or store register, a coupon might be printed onor along-side a transaction receipt. In an embodiment, block 1890 maymore specifically comprise the offer server storing offer activationdata that indicates that the offer is available for use by the consumer.In an embodiment, block 1890 is responsive to the offer server receivinga message from the device to which the consumer provided the input ofblock 1885. In an embodiment, block 1890 is further responsive to anoptional intermediary step of sending an offer activation mechanism toan electronic address associated with the resolved consumer entity. Forexample, in response to block 1885, a link to an address at an offerserver for obtaining a coupon for the offer may be emailed to theconsumer. Or a link may be texted to the consumer, posted on a socialnetwork, included in a statement in association with a transaction, andso forth. The consumer may then select the link to activate the offer.

Block 1895, which is optional, comprises the offer server tracking thatthe offer was activated distributed by storing various tracking data asdescribed herein.

Pre-Activated Offers

In an embodiment, in response to certain triggers like receipts, and soforth, certain offers are automatically activated for a consumer.Automatically activated offers are offers that become activated for aconsumer without the consumer explicitly requesting activation of theoffer. Various auto-activation rules may be defined on a global scale,and/or auto-activation may be an offer parameter definable by an offerprovider. Such auto-activation rules may be associated with, among othercontexts, a consumer's device, the device's location, a specific offer,items in a consumer's basket, and so forth. In an embodiment, alltargeted offers are auto-activated. In an embodiment, the highest nrecommended offers are pre-activated.

In an embodiment, blocks 1870, 1880, and 1885 of flow 1800 are optional.In this embodiment, the offer is activated for the consumer entityautomatically, per auto-activation rules.

In an embodiment, an offer distributor keeps track of how many timeseach offer is activated for various purposes. For example, the offerdistributor may charge offer providers fees based on how often theiroffers are activated. An offer distributor might also use revenue peractivation as a metric for purposes such as tuning recommendationengines and targeting engines, or advertising of how successful theoffer distributor is to potential providers. It is therefore in theoffer distributor's interest to ensure that auto-activation rules areemployed cautiously. For example, in one embodiment, auto-activationrules may be used only for consumers highly likely to redeem anactivated offer, or for relatively rare promotions, where the provideris willing to pay for a large number of potentially unredeemedactivations of an offer with the hope that the auto-activation of theoffer might make consumers more aware of a product than would the mereexistence of the offer.

Ambiguous Consumer Identifiers

In some embodiments, the offer server may determine that the consumer isalmost equally likely to be one of several entities. Block 1850 may, insuch embodiments, allow the consumer to be resolved to multiple consumerentities. Offer(s) may be selected based on combined criteria from themultiple consumer entities. In an embodiment, the consumer may only beresolved to multiple entities if a coupon is going to be printed at thedevice.

In other embodiments, the offers are selected based on combined criteriaregardless of how the offer will ultimately be activated, but theconsumer is expected to provide unambiguously identifying informationupon specifically selecting to activate the offer. For example, theconsumer-operated device may be a device that interacts with manyconsumers, such as a touch-screen kiosk in a public area. Block 1420comprises sensing the consumer identifying information in a manner thatis largely passive with respect to the consumer. For example, theconsumer may simply walk by the kiosk without expressing an intent tointeract with the kiosk, but signals from a nearby device or a facialrecognition algorithm may nonetheless provide a hint as to identities ofconsumers within the vicinity of the kiosk. The kiosk then displays theoffer data, per block 1480. Upon the consumer expressing interest in aspecific offer by, for example, touching the screen of the kiosk, thekiosk solicits more unambiguous information about the consumer, such asan email address or phone number. In an embodiment, the kiosk may listpossible matching consumer identifiers, such as a portion of an emailaddress, on the screen, and the consumer may quickly identify herself byselecting one of these possible identifiers.

In yet other embodiments, the offer may be activated for each of themultiple consumer entities. In an embodiment, the offer is activated forboth consumer entities only if those multiple entities are relatedentities, such as entities belonging to the same household or who liveat the same address. In an embodiment, an offer server may further beconfigured to allow only one of the entities to actually redeem theoffer.

Retailer-Based Offer Distribution

FIG. 22 illustrates an example flow 2200 for providing offers atendpoints operated by retailers, according to an embodiment. While flow2200 is described in terms of the architecture described for system 1300of FIG. 13A, flow 2200 is but one example of a flow that may be used forproviding offers in the system 1300. Other flows may comprise additionalor fewer elements, in potentially varying orders. Also, flow 2200 isapplicable to variations of system 1300 as well, with little or nomodification.

Block 2210 comprises storing offer data describing a plurality of offersfor a plurality of different items. For example, offer server 1380 maystore in offer data repository 1385 data describing offers created byvarious offer providers.

Block 2215 comprises providing, over a first network, to each retailerof a plurality of retailers, a transaction interface. For example,transaction aggregation system 1350 may expose an API for retailers 1310to submit transaction logs over the Internet.

Block 2220 comprises receiving transaction details for a plurality oftransactions from the plurality of retailers via the transactioninterface. For example, retail data centers 1320 may be configured toperiodically submit transaction logs via the API of transactionaggregation system 1350. The transaction details include, for eachtransaction of the plurality of transactions, at least line item detailsfor each item of a plurality of items purchased in the transaction.

Block 2230 comprises storing the transaction details. For example,transaction aggregation system 1350 may create, in transaction datastore 1355, a new record comprising the transaction details for each logreceived from retailers 1310.

Block 2235 comprises providing, over a second network, to at least afirst retailer of the plurality of retailers, an offer provisioninterface. For example, offer server 1380 may expose one or more APIsfor receiving requests to provide offers over a network, such as theInternet. The APIs may be accessible to terminals and other endpoints atsome or even all of retailers 1310. The first network may be the sameas, or different from the second network.

Block 2240 comprises receiving, via the offer provision interface, fromthe first retailer, a request to provide offers, the request includingcontextual data. The contextual data may be, for instance, a name, phonenumber, RFID, a device identifier, a loyalty card number, a credit cardnumber, items that were recently purchased in a transaction, thelocation of the particular endpoint, the time and date, a transactionnumber, and so forth. For example, a checkout terminal at a firstretailer 1310 may submit credentials provided in a recent or pendingtransaction to offer server 1380. Or a kiosk at a point-of-sale mayallow a consumer to swipe his or her phone, and then send credentialsfrom the phone, such as a device identifier or shopping list, to offerserver 1380. In an embodiment, the contextual data includes a uniqueconsumer entity identifier, which may have previously been provided tothe requester over a consumer entity resolution API of offer server1380.

Block 2245 comprises matching the contextual data to a set oftransactions described in the transaction details for the plurality oftransactions. For example, offer server 1380 may resolve the contextualdata to a consumer entity in consumer data store 1358, as describedherein, and then retrieve all transaction logs in transaction repository1355 that are mapped to that consumer entity. Or, offer server 1380 maysimply search the transaction data store 1355 for all transaction logswith matching or similar contextual data. In one embodiment, the matchedtransactions are filtered for those that occurred at the first retailer.In another embodiment, the matched transactions include those thatoccurred at other retailers. In yet another embodiment, whether thetransactions include those that occurred at other retailers may differfrom retailer to retailer. For example, the offer distributor mayrequire that a first retailer allow other retailers to receive offersbased on the first retailer's transactions in order for the firstretailer to receive offers based on the other retailers' transactions.

Block 2250 comprises, based at least on line item details from thematched set of transactions, selecting one or more offers from theplurality of offers in response to the request. For example, offerserver 1380 may select offers for items that appear in the most recentmatched transactions, or are complimentary to the items that appear inthe most recent matched transactions. Or offer server 1380 may analyzethe transactions for purchasing trends revealed by the matchingtransactions, and select offers based on those trends. Or offer server1380 may select offers for items that are purchased most frequently. Inan embodiment, the line item details include redeemed offers. Offersever 1380 may thus also base the selection on which offers the consumerpreviously redeemed. A variety of other offer selection techniques mayalso or instead be utilized, including targeting the offers to thecontextual data and/or generating a recommendation using a rankingfunction that is based at least on signals derived from the contextualdata.

In an embodiment, the selection comprises, based at least on line itemdetails, calculating an estimated retailer profit metric, specific tothe first retailer, for showing the offer within a context described bythe contextual data. The one or more offers are then selected basedthereon. For example, the estimated retailer profit metric may be ascore from a scoring function optimized for maximizing estimatedretailer profit. In an embodiment, the selection comprises, based atleast on the line item details, calculating an estimated revenue perimpression or revenue per activation metric for showing the offer withina context described by the contextual data and selecting the one or moreoffers based thereon. That is, depending on the embodiment, thepotential revenue for selecting an offer may be calculated relative toimpressions, which are the number of times consumers view informationabout an offer, or activations, which are the number of times an offeris specifically activated for future use by a consumer. A yet thirdalternative would be to estimate revenue per unique impressions, or thenumber of unique consumer entities to whom offer information has beenprovided. In all cases, revenue may be calculated from the offerprovider perspective, retailer perspective, and/or offer distributorperspective, depending on the embodiment. In an embodiment, theestimated revenue per impression or revenue per activation is a scorefrom a scoring function optimized for maximizing revenue per impressionor revenue per activation.

Block 2260 comprises, responsive to the request, providing the firstretailer with offer data describing the selected one or more offers. Forexample, offer server 1380 may provide XML formatted offer details.Retail data center may then reformat and display this data at acorresponding end point. As another example, offer server 1380 mayprovide HTML or JavaScript code containing the offer details for onlinestore 1332 to embed within its own web site. In an embodiment, therequest of block 2240 is for a receipt that includes embedded offers,and the response of block 2260 is therefore formatted as a receipt. Thereceipt may be formatted in accordance to a pre-defined receipt format,or based on a template previously uploaded by the requestor. In anyevent, any suitable technique of formatting or transmitting the offerdata may be used.

Block 2270 comprises receiving a request to activate a particular offer,of the selected offers, for a particular consumer entity that matchesthe context data. The request may come from the first retailer itself,or it may come directly from a consumer's device. For example, aretailer 1310 may prompt a consumer to select an offer, or mayautomatically select one of the offers on behalf of the consumer. Or,the retailer may send the consumer a presentation of offer details onthe consumer's own device. The consumer may select a particular offerand the device may consequently transmit a request to activate the offerto offer sever 1380.

Block 2280 comprises activating the particular offer for the particularconsumer entity. For example, offer server 1380 may create a new offeractivation record for the particular offer in activation data 1388, andthen map the offer activation record to the particular consumer entity.

Block 2290 comprises sending, to at least the first retailer, andpotentially multiple other retailers, activation data indicating thatthe particular offer has been activated for the particular consumerentity. In accordance with other techniques described herein, theconsumer is thus enabled to redeem the particular offer at any of theretailer(s) to whom thee activation data has been sent.

3.3. Offer Redemption

Retailer-Based Redemption

The applications already referenced describe example process flows foroffer redemption. FIG. 19 illustrates another example process flow 1900for offer redemption with a retailer.

Block 1910 comprises receiving, at the retailer, item data thatspecifies one or more items that a consumer intends to purchase in apending transaction. The item data comprises basket-level details forthe one or more items, including any suitable item identifiers. Itemidentifiers may include, without limitation, UPC symbols, RFIDs, NFCtokens, barcodes, part numbers, service codes, and so forth. Asdescribed herein, the item data may be received through a point-of-salecheckout terminal, retailer website, or other endpoint through which theretailer is capable of conducting a transaction.

Block 1920 comprises receiving, at the retailer, credential data thatspecifies one or more identifiers for the consumer. The credential datamay include, without limitation, a credit card number or otherpayment-based identifier, a loyalty card identifier, a phone number, anaddress, biometric data, an email address, a user name, and/or apassphrase. Depending on architectural constraints, business rules,and/or other reasons, different retailers may collect different types ofcredential data. For example, one retailer may simply use a credit cardnumber as an identifier, while another may request a loyalty card or aphone number. Credential data may be collected implicitly, in that it iscollected passively from the consumer, or as part of the paymentprocess. Additionally, or alternatively, the retailer may explicitlyprompt the consumer to provide credential data for the purpose ofredeeming offers that have been activated for the consumer. Credentialdata may be collected via any suitable interface that is connected tothe endpoint with which the consumer is interacting. Example interfacesinclude, without limitation, a card-swiper, NFC reader, smartphone,checkout register, and website.

Block 1930 comprises resolving the credential data to a consumer entity,as described elsewhere in the application. The resolution process mayoccur at the retailer, or the retailer may use a server-based API tosubmit the credential data to another server, such as an offer server,so that the server may perform the resolution process. The retailer mayexplicitly request that the server resolve the consumer entity for theconsumer, or resolving the consumer entity may be a step performed bythe server in response to other requests that include credential data.For example, the retailer may include the credential data in a requestto the server to provide activated offer(s) or eligible activatedoffer(s), per blocks 1940 or 1950 below. In the former case, the servermay then return an identifier for the resolved consumer entity to theretailer. In the latter cases, the server may not necessarily return aresolved consumer entity to the retailer. In either case, if thecredential data does not unambiguously resolve to a single consumerentity, the retailer may solicit additional credential data from theconsumer. Thus, block 1930 may to some extent be concurrent with block1920.

In an embodiment, block 1930 may be a trivial step. There may, forinstance, be a direct mapping of activated offers to loyalty accounts.Thus, if the consumer specified a loyalty card number in the credentialdata, there would be no need for an actual consumer entity resolutionprocess, since the loyalty account is synonymous with the consumer'sresolved entity.

Block 1940 comprises identifying which one or more offer(s) availablevia the offer server are currently activated for the resolved consumerentity. The offers may have become activated using any suitabletechnique described herein. The retailer may perform this step directlyif it has a cached copy of a mapping between resolved consumer entitiesand activated offers. If not, the offer server may perform block 1940.In the latter case, identifying the activated offer(s) may comprise, forinstance, the retailer sending an identifier for the resolved consumerentity or the credential data to an offer server, such as describedherein.

The identification process may involve looking up all activated offersthat are mapped to the resolved consumer entity, or the activated offersmay be pre-filtered to eliminate certain offers that are guaranteed tobe inapplicable to the transaction. For example, the offer server mayeliminate those activated offers whose terms are clearly not met bycontext data associated with the retailer's request, such as time, date,location, retailer, retailer type, and so forth.

In an the embodiment, the offer server may respond to the retailer witha list of activated offer identifiers. Alternatively, the offer servermay perform subsequent steps based on the identified activated offers,without providing the complete set of activated offers to the retailer.

Block 1950 comprises determining for which of the activated offer(s) thepending transaction is eligible. The determining includes comparinginformation about the items specified by the item data of block 1910 toeligibility criteria associated with the activated offer(s). Forexample, the retailer may periodically receive offer metadata describingitem identifiers for which various offers may be redeemed. The retailermay compare the item identifiers for each particular activated offer toitem identifiers in the item data of the pending transactions. Thoseoffers whose item identifiers match those of the pending transaction maybe applied to the pending transaction. Of course, a wide variety ofother criteria may also or instead be utilized to identify for whichactivated offers the pending transaction is eligible.

In some embodiments, block 1950 may be performed by the retailerresponsive to receiving a list of activated offer(s). Offer metadatadescribing various eligibility criteria may have been provided to theretailer in asynchronous batch operations prior to the pendingtransaction. Offer metadata may instead be provided with the list ofactivated offer(s) returned in block 1940, or in response to asubsequent request by the retailer to the offer server.

In other embodiments, block 1950 is performed by the offer server. Suchembodiments may require that the retailer provide the item data to theoffer server in one of blocks 1930 or 1940. In such embodiments, theoffer server responds to the retailer's request of block 1930 or 1940with a list of exactly which offers should be applied to the pendingtransaction.

Block 1960 comprises the retailer applying the offer(s) identified inblock 1950 to the transaction, using any suitable technique.

Block 1970 comprises the retailer completing the transaction, with theapplied offer(s). Block 1970 may comprise the retailer receiving paymentdetails from the consumer, if such details were not already receivedwith, for instance, the credential data. Depending on the payment type,block 1970 may further comprise the retailer communicating with apayment provider to authorize payment for the transaction.

Block 1980 comprises the offer server marking those offer(s) applied tothe transaction as inactive for the consumer, if any relevantdistribution limits have been reached with respect to the offer(s). Ifthe retailer performs block 1950, block 1980 may comprise the retailerreporting which offer(s) were actually applied to the transaction.Otherwise, block 1980 may simply be responsive the retailer reportingthat the transaction was completed, since the offer server would alreadyknow which offer(s) were identified as eligible in block 1950. In anembodiment, block 1980 is responsive to the offer server receiving atransaction log generated by the retailer for the completed transaction.In other embodiments, retailers may report offer redemptions to theoffer server separately from transaction logs, to ensure that redeemedoffers are marked inactive for the resolved consumer entity as quicklyas possible.

Block 1999 comprises the retailer clearing the redeemed offer(s) with aclearinghouse, such as the digital clearinghouse described herein.

Flow 1900 is but one example of how a retailer may facilitate offerredemption. Other flows may involve fewer or additional elements inpotentially various arrangements.

Payment Provider-Based Redemption

FIG. 20 illustrates an example process flow 2000 for offer redemption bya payment provider, according to an embodiment. Block 2010 comprises theretailer receiving item data for a pending transaction with a consumer,as described with respect to block 1910 above.

Block 2020 comprises receiving, at the retailer, payment details for theconsumer. Payment details include at least a payment provider identifierand credential(s) by which the payment provider may locate a paymentaccount number for the consumer, such as an account identifier and/orpassphrase. Receiving payment details as described here and in otherflows may comprise, for instance, the consumer or an attendant swiping acredit card in a credit card reader coupled to a checkout terminal, theconsumer bringing a smartphone or other NFC tag carrier in proximity ofan NFC reader at the checkout terminal, the consumer or attendantentering identifiers such as those of a checking account or credit cardinto a checkout terminal, the consumer entering credit card informationor other credentials into a website, the consumer instructing asmartphone to transmit payment information to the retailer, and soforth. Alternatively, block 2020 may comprise the consumer transmittingpayment details directly to the payment provider, thus avoiding the needfor the retailer to retransmit the payment information in block 2040below.

Block 2030 optionally comprises receiving, at the retailer, additionalcredential data, as in block 1920. Block 2040 comprises the retailersending pending transaction details, payment information, and optionaladditional credential data to the payment provider identified by thepayment information. The pending transaction details include a totaltransaction payment amount being requested from the identified paymentaccount. The pending transaction details may further include, dependingon the embodiment and/or identified payment provider, some or all of theitem data received in block 2010, and/or a variety of transactioncontext data, such as retailer name, location, time, and date.

Block 2045 comprises the payment provider authorizing the transactionusing any suitable technique. For example, the payment provider mayauthorize the transaction upon verifying that the identified paymentaccount has sufficient funds to pay for the pending transaction, andthat the pending transaction passes various fraud prevention algorithms.The payment provider responds to the retailer with an indication ofwhether the transaction was authorized.

Block 2050 comprises resolving the payment information and the optionalcredential data to a specific consumer entity. The payment provider mayperform the resolution directly, or the payment provider may communicatewith the offer server to effect the resolution process in the samemanner as described with respect to the retailer in block 1930. In anembodiment, block 2050 may be a trivial step. There may, for instance,be a direct mapping of activated offers to payment accounts, and thusthere would be no need for an actual consumer entity resolution process.Rather, the identified payment account is synonymous with the consumer'sresolved entity.

Block 2060 comprises identifying which one or more offer(s) availablevia the offer server are currently activated for the resolved consumerentity. Block 2065 comprises determining for which offer(s) thetransaction is eligible. These blocks proceed in similar manner toblocks 1940-1950 above. If the actual item data was not communicated tothe payment provider, block 2065 is performed based on transactiondetails other than the actual items purchased, such as the totaltransaction amount or purchase frequency.

Block 2070 comprises the payment provider redeeming the offer(s)identified in block 2065. Block 2070 may comprise, for instance, thepayment provider reducing the amount that the consumer will be billedfor the transaction by amount(s) specified by the identified offer(s),or by adding the amount(s) as credits to the consumer's payment account.

Block 2080 comprises the offer server marking redeemed offer(s) asinactive. The offer server will perform block 2080 in response to anindication that the payment provider redeemed the offer(s) in block2070. The indication may be, for instance, a direct redemption messagesent by the payment provider, a transaction log generated by the paymentprovider, or a transaction log generated by the retailer.

Depending on when block 2045 is performed relative to block 2070, block2090 may optionally be performed. Block 2090 comprises the paymentprovider reporting the credit or reduced transaction amount back to theretailer, so that the retailer can advise the consumer as to whichoffers were redeemed. For example, a point-of-sale register may promptan attendant to advise the consumer that an offer was redeemed. Or, theretailer may print information about the redemption on a screen or areceipt.

Alternatively, or in addition, block 2095 may be performed. In block2095, a digital receipt provider displays the credit and/or reducedtransaction amount in a digital receipt, as described herein. Yetanother alternative or additional step is for the payment provider toreport the redeemed offer in a billing statement.

Block 2099 comprises the payment provider clearing the redeemed offer(s)with a clearinghouse, such as the digital clearinghouse describedherein.

Flow 2000 is but one example of how a payment provider may facilitateoffer redemption. Other flows may involve fewer or additional elementsin potentially varying arrangements. Some or all of blocks 2050-2095need not be performed synchronously with blocks 2010-2040. For example,some or all of blocks 2050-2095 may be performed in a subsequenttransaction log analysis phase, such as at the end of a billing cycle orat the end of a business day.

Cross-Transactional Offers

The techniques described herein allow for retailers or payment providersto apply offers whose terms are not limited to the transaction detailsof a single transaction. Such offers are possible when retailers andpayment providers have access to transaction details for multipletransactions. For example, a retailer or payment provider may wait toapply offers for some time after transactions have been completed, suchas at the end of the business day, or during periodic statement windows.Thus, multiple transactions may be examined to determine if any offerconditions have been met.

As another example, a retailer or payment provider may be provided withlive access to transactional data collected by a transaction aggregationsystem. For instance, a transaction aggregation system may feature aninterface by which a retailer or payment provider may query the systemfor a list of items recently purchased items and/or other aggregate oreven line-item transaction details. The retailer may use thisinformation determine whether the terms of any cross-transactionaloffers have been met. As another example, an offer server may feature aninterface by which a retailer or payment provider may query the offerserver as to whether the purchase of certain items would complete theterms of any offers activated for a certain consumer. The offer servermay respond with a list of any activated offers whose terms would bemet, even if those terms are only met in conjunction with transactiondetails from previous transactions.

Consequently, offers may be conditioned upon details from multipletransactions, even if those transactions occur at different retailers.For example, an offer may require that a consumer purchase a certainmovie at an online store, and then purchase a certain entrée from acertain restaurant. Or, as another example, an offer may require that aconsumer purchase a certain combination of grocery items within aparticular time period, without regard to where those items werepurchased. Or, as another example, an offer may require that a consumeruse a certain credit card to purchase a certain total amount ofmerchandise from a certain retailer within a particular billing period.

For example, when responding to a retailer with available offers, theoffer server may advise the retailer that in view of what the consumerhas already purchased, an additional purchase of grocery item x willtrigger a discount y. If that grocery item x is not in the consumer'sshopping cart, the retailer may even advise the consumer that they havean activated offer that can be triggered by purchasing item x.

Since certain cross-transactional offers may involve purchases atmultiple retailers, when a retailer applies a cross-transactional offer,the retailer may be provided with reference data by which aclearinghouse may validate the fact that all terms of an offer wereindeed met. For example, the retailer may be provided with a validationcode that it may forward to the clearinghouse. The clearinghouse maythen communicate with the transaction aggregation system or offer serverto ensure the validity of the validation code.

In an embodiment, most offers are implicitly presumed to require thatall items are purchased in a single transaction. However, an offer'sterms may instead specify that the items are to be purchased in acertain time period, regardless of how many transactions are involved inthe purchase of those items. In an embodiment, depending on the offerterms, the offer must have been activated prior to the entire timeperiod. In an embodiment, depending on the offer terms, the offer musthave been activated before the final transaction involved. In anembodiment, depending on the offer terms, the offer may be activatedretroactively. It should be noted that retroactive activation may bepossible for both regular and cross-transactional offers.

3.4. Consumer Entity Resolution

As mentioned in other sections, various consumer entity resolutiontechniques may be utilized to disambiguate consumer identities withintransactional, offer distribution, and event tracking contexts. In someembodiments, simple consumer identification schemes may be used, such asa one-to-one mapping between consumer entities and certain identifiers,or combinations of identifiers, such as loyalty card numbers incombination with a retailer identifier, or credit card number. In suchembodiments, customer records may be stored in any combination oftables, such as a single master customer table that combines recordsfrom multiple retailers or entities, or separate tables for eachretailer/entity that provides customer data.

In an embodiment, a hierarchy of consumer records from differentpartners is analyzed to form a plurality of master consumer records. Themaster consumer records may have multiple values for each of severalfields, each of which is associated with trust scores and/or confidencescores. For example, some credentials, such as social security numbers,or combinations of credentials, may be much more reliable indicators ofa consumer's identity than other credentials, such as phone numbers.Moreover, some credentials may be ambiguous because they actually belongto two or more people. Examples of such ambiguous credentials mayinclude, without limitation, certain household identifiers and creditcard numbers. Thus, the more reliable and/or unique the credential, orcombination of credentials, the higher its trust score. As anotherexample, some identifiers may appear in many different entity records,and thus the system may assign a higher confidence score to thoseidentifiers than other identifiers that appear only in one or two entityrecords. These trust scores and/or confidence scores allow the system tofigure out how likely it is that two different records from twodifferent sources belong to the same person. The system, in essence,dynamically learns who consumers are. The system is constantly updatingits master consumer records as new data becomes available.

FIG. 21 illustrates an example flow 2100 of storing and accessingconsumer records for differentiating between consumers by resolvingcredentials to consumer entities, according to an embodiment.

Block 2110 comprises receiving multiple sets of consumer records frommultiple sources, sometimes also denoted collections of records. Thesecollections may also be referred to as “source collections.” Themultiple sources may include a variety of source types, depending on theembodiment, including public records and financial institutions. In oneembodiment, the sources include at least a first retailer and a secondretailer that is different from the first retailer, and consequently themultiple source collections include a first collection from the firstretailer and a second collection from the second retailer. For example,different retailers may configure their respective data centers toperiodically upload their consumer records, or a portion thereof, to theoffer server.

Each particular collection of the multiple source collections has acorresponding particular consumer record structure, and each particularconsumer record structure has particular fields for which one or more ofthe consumer records in the particular collection have values. Somesources may maintain different data about their consumer records indifferent formats. For example, the first collection may have a firstconsumer record structure and the second collection may have a secondconsumer record structure, wherein the first consumer record structurehas first fields that differ from second fields of the second consumerrecord structure. This may occur in many circumstances—for example, onesource may collect driver's license numbers and demographic informationfor their consumers, but nothing else, whereas another source maycollect social security data and credit card numbers, but nothing else.

In an embodiment, once received, the consumer records in each sourcecollection may be subject to various normalization processes to ensurethat similar field types, such as phone numbers or names, are similarlyformatted. The offer distributor may store the source collections usinga common normalized structure, even if the source collections arestructured differently upon receipt from the sources. However, in anembodiment, a common normalized structure is not necessary.

Block 2120 comprises, for one or more particular collection of themultiple source collections, assigning trust scores to the particularfields of the particular collection. The trust scores quantify howaccurate the different fields of the different collections are perceivedto be. For example, a first phone number field in a first source'scollection may be known to be generally inaccurate, while a second phonenumber field in a second source's collection may be highly accurate. Thefirst phone number field may thus be assigned a lower trust score thanthe second phone number field. Thus, for example, a first field of thefirst source collection has a different trust score than a similarsecond field of a second source collection.

In an embodiment, the assignment of trust scores may be a dynamic andongoing process, in which the trust scores are repeatedly “re-learned”through machine learning techniques, based on factors such as how muchagreement there is, on average, between the similar fields of differentsources, as well as other feedback mechanisms such as consumer inputinto the offer distribution system. In an embodiment, trust scores maybe set manually by the offer distributor as needed. In some embodiments,trust scores may be assigned for entire source collections, such thatall fields in a collection have the same trust score. In an embodiment,an entire source collection may be assigned an initial trust score, butthe trust scores for its fields may change over time via theabove-described techniques.

Block 2130 comprises establishing correlations between differentconsumer records in different collections of the multiple sourcecollections. Establishing the correlations may comprise, for instance,correlating consumer records that have similar values for one or moresimilar fields in two or more records. Correlation metadata identifyingthe correlations is stored separately, or in a master consumer record asdescribed below. Correlations may be reevaluated on an ongoing basis.For example, correlations may be re-evaluated periodically and/orwhenever an updated source collection is received from a source, perblock 2110.

Groups of similar fields are identified manually or by various matchingtechniques. Each group comprises a similar field from each of at leasttwo of the source collections. The values of each similar field for eachconsumer record in each source collection are compared to the values ofcorresponding similar fields for each consumer record in each othersource collection. Records from different collections whose similarfields have values that match to a certain degree of confidence, arefound to be similar to each other. Matching values in certain fields,such as fields with highly unique numbers, may be weighted higher inidentifying a correlation than matching values in less unique fields,such as name, gender, or age. In some embodiments, the values forcertain unique fields such as social security numbers or driver licensenumbers must match in order for a correlation to be established.However, the absence of a value in one of the consumer records for thecertain unique fields can be ignored if other designated fields matchwith a high degree of confidence.

The number of fields that must match in order to establish a correlationmay vary, depending on the types of collections that are received fromthe sources. Depending on the field, a match may require exactly thesame values, such as with identification numbers or phone numbers, or amatch may require highly similar values, such as with names anddemographic data.

In an embodiment, the correlations are established, in part, based uponthe trust scores. For example, a match, or lack thereof, may be ignoredif a corresponding source field has a low trust score. In an embodiment,past purchase behavior is also used to establish correlations, such asitems purchased, where purchased, and frequency of purchase.

Block 2140 comprises generating a master collection of consumer recordsby generating master consumer records based on the correlations. Eachmaster consumer record describes a different consumer entity. Each of aplurality of master consumer records are linked to at least twodifferent correlated consumer records from at least two differentsources. Master consumer records are also generated for each record thatwas not correlated to any other record, though these master consumerrecords may also later be linked to two or more correlated records, asadditional information is added to the system and additionalcorrelations are discovered.

Each master consumer record includes fields from a master set of fields.The master set of fields may comprise one master field for each group ofsimilar fields identified in the source collections, as well as a masterfield for each source collection field that is not in a group of similarfields. In an embodiment, however, the master fields may only correspondto a subset of the source collection fields. Additionally, the masterfields may or may not contain other fields that do not directlycorrespond to any source collection fields.

Block 2150 comprises identifying values for master fields based oncorresponding source fields and their associated trust scores. Theidentifying may more specifically comprise identifying one or morevalues for at least one particular master field of a particular masterconsumer record based at least on: a first value for the first field ina first consumer record of the first collection, a second value for thesecond field in a second consumer record of the second collection, andthe different trust scores assigned to the first field and the secondfield. In an embodiment, identifying the one or more values comprises,deciding which one or more values of the first value and the secondvalue to store in the master consumer record based at least on thedifferent trust scores. In an embodiment, identifying the one or morevalues comprises, in response to a query that requests the one or morevalues for the particular field, querying the first consumer record fromthe first collection for the first value, querying the second consumerrecord from the second collection for the second value, and decidingwhich one or more values of the first value and the second value toreturn based at least on the different trust scores.

In an embodiment, each master consumer record field is assigned multiplevalues. The multiple values are each assigned a trust score and/orconfidence score based on the source(s) from which each valueoriginated. In other embodiments, some or all master consumer recordfields comprise a single value selected from the different sourcecollections. The source collection field(s) that correspond to aparticular master consumer record field are ranked using a function ofthe trust scores and/or confidence scores. The particular masterconsumer record field is then assigned the value of the highest rankingsource collection field. In an embodiment, each field of the masterconsumer record is linked to the field of the source collection(s) fromwhich the value of the master consumer record field originated, therebyallowing for easy updates to the master consumer record if the sourcecollections and/or trust scores change.

Block 2160 comprises receiving a query that selects for one or morecredential values in one or more particular master fields. Such a querymay be issued by a number of entities in a number of contexts. Forexample, the query may be issued by a retailer or offer distributor inresponse to a consumer presenting the one or more credentials at thetime of checkout. As another example, the query may be issued by apayment provider upon detecting the one or more credentials in atransaction log. As another example, the query may be issued by areceipt server in response to a consumer, having the one or morecredentials, requesting access to his or her receipts. As yet anotherexample, the query may be issued by an advertiser or offer distributorin response to detecting an offer distribution opportunity involving theone or more credentials.

Block 2170 comprises locating master consumer records whose one or morefields match the one or more credential values in the query. Again, amatch as described herein may require exact matches, or similar values,depending on the type of data represented by the field. In anembodiment, certain fields, such as unique fields, must match thecorresponding credential value(s) specified in the query, whereas otherfields need not necessarily match. These fields may nonetheless impactthe ranking process in block 2180 below.

Block 2180 comprises ranking the master consumer records located inblock 2170 based on at least one or more of: the extent to which themaster consumer records match the specified one or more credentialvalues, the trust score(s) associated with the values from the one ormore master fields that are subject to the query, and/or the confidencescore(s) associated with the values from the one or more master fieldsthat are subject to the query. In an embodiment, these and other factorsmay be weighted within a ranking function to score each of the locatedmaster consumer records.

For example, multiple master consumer records may be located for thesame credential values. However, based on the trust scores associatedwith these credential values in the respective master consumer records,one of the master consumer records may be a significantly moretrustworthy match, and thus ranked higher. Or, based on the confidencescores, it may be apparent that a particular credential value appearsmuch more frequently in the source consumer records correlated to afirst master consumer record than in the source consumer recordscorrelated to a second master record. Thus, the first master record isranked higher.

Block 2190 comprises returning one or more values associated with thehighest ranked master consumer record(s). The exact values returned mayinclude any values stored in or mapped to the master consumer record,and will depend upon the query of block 2160. For example, one type ofquery may request that a unique master consumer record identifier isreturned, so that the requestor may subsequently query for receipt oroffer records associated with the master consumer record. Another typeof query may request source collection identifiers correlated to themaster consumer record. Yet another type of query may request the fullmaster consumer record. In an embodiment, the first value is assigned tothe particular field for a plurality of master consumer records; and themethod comprises further receiving a query that selects for the firstvalue; and identifying one or more master consumer records to returnbased on trust scores assigned to different fields of different sourcecollections from which the plurality of master consumer records weregenerated.

When multiple master consumer records are ranked equally, or within athreshold score of each other, an ambiguous response may be returned.The ambiguous response may vary depending on the embodiment. Forexample, a designated error code may be returned, or values from morethan one of the multiple master consumer records may be returned.

Variations

Flow 2100 illustrates but one example flow for resolving consumerentities. Other flows may feature additional or fewer elements, inpotentially varying orders. For example, the sources from block 2110 mayinclude only one retailer, but also include registration informationfrom the offer provider itself and/or historical data. The sources mightalso or instead include data purchased from data brokers. As anotherexample variation, master consumer records may further include or bemapped to a variety of data fields that are collected by the offerdistributor as consumers interact with the offer server. For example,some such fields that may be used to resolve the consumer entity includehistorical location data, and correlations of the historical locationdata (or the lack thereof) to other consumer activities within a sametime frame. In an embodiment, the master fields include aggregatedtransaction data. Hence, a consumer entity may be resolved in part bymatching items in a consumer's basket to items historically purchased bythe consumer.

In an embodiment, a method comprises: storing consumer recordscomprising data collected from different sources, wherein each of theconsumer records includes a plurality of values for a plurality ofattributes, including one or more consumer credentials; storing logs ofprevious actions taken by consumers in association with the differentsources, wherein the logs include credentials by which the logs aremapped to the consumer records; receiving a request to provide access toparticular content, wherein the request includes one or more particularcredentials and metadata associated with the request; wherein a firstconsumer record and a second consumer record share the same one or moreparticular credentials; selecting a particular consumer record, of thefirst consumer record and the second consumer record, based on comparingthe metadata associated with the request to information stored in orderived from the logs of previous actions taken by consumers; andresponding to the request based on consumer access data specific to theselected particular consumer record.

For example, the master consumer records as described above may be usedto enforce access control rules with respect to digital content ordigital offers. Each master consumer record is associated with one ormore activated offer records. Each of the activated offer recordsspecifies an offer or content item to which the master consumer recordhas been granted access. Moreover, each activated offer record may bemarked with status indicators such as redeemed, available, expired, andso forth, to enforce distribution limits on the digital offers and/ordigital content. In an embodiment, on account of the various consumerrecord correlations described herein, an offer previously marked asredeemed in response to a request that presented a first credentialassociated with a particular consumer record is not provided in responseto the request even though the request contains a different credential,because the different credential also resolves to the particularconsumer record.

In an embodiment, the first consumer record and the second consumerrecord include, in addition to the one or more particular credentials,one or more other credentials that are not equivalent. The one or moreother credentials were not included in the request, however, and thuscould not be used to disambiguate the consumers.

In an embodiment, the method comprises matching potentially ambiguoustransaction logs to consumer records, based on comparing transactiondetails from the potentially ambiguous logs to those of logs thatpresent unambiguous credentials. In an embodiment, the compared detailsinclude any or all of a location associated with the transaction, basketdata, and/or time or day of week.

FIG. 30 illustrates a flow 3000 for differentiating between consumerswho provide ambiguous credentials based on historical transactionrecords relating to those consumers, such as items in which a consumerhas previously expressed an interest, according to an embodiment. Flow3000 may be useful, for example, in providing targeted offers to membersof a family who present the same loyalty card at a store, or in anyother situation where the credentials presented by a user do notunambiguously resolve to a single customer record unambiguously. Flow3000 is but an example of a flow that can be used to differentiatebetween consumers. Other flows may include additional or fewer elementsin potentially varying arrangements.

Block 3010 comprises storing customer records from a plurality ofsources, as described in connection with the embodiments of FIGS. 21 and34. Block 3020 comprises storing various types of historical transactionrecords. In general, the customer records stored in block 3010 mayinclude any of the historical transaction records discussed inconnection with the embodiment of FIG. 13A, to the extent suchhistorical transaction records relate directly or indirectly toconsumers or transactions conducted by consumers. Another example ofsuch historical transaction records include behavioral logs, each havingcredentials that map to a particular customer record. The behaviorallogs may include, for instance, transaction logs, event logs, offertracking logs, location tracking logs, shopping list logs, or any othertype of behavioral logs described herein.

Other examples of historical transaction records that may be stored inblock 3010 include, with respect to one or more electronic transactionsthat were conducted in the past by one or more consumers, informationregarding a universal product code, a quantity of product purchased, anumber of items purchased, a transaction amount, at least a portion of acredit card number used, a payment identifier used, a secure paymenthash key, a data processing system, a merchant or retailer facility,time or date when a transaction took place, one or more offers activatedor redeemed, customer name, phone number, pin number, password, code,loyalty card number, RFID data, a device identifier, one or more itemsthat were purchased in a previous or concurrent transaction, or atransaction number.

Block 3030 comprises receiving a request to provide access to particularcontent. The request may occur at any suitable endpoint to which anoffer server or general purpose content server provides offers orcontent. The request includes credential(s), and may be associated withcontextual transaction data, possibly in the form of metadata,describing one or more behavioral characteristics of a consumer. Theparticular content may be, for example, an offer that a consumer wishesto activate, an activated offer that a consumer wishes to redeem, areceipt, a list of offer recommendations or targeted offers,downloadable digital content, and so forth. As described in othersections, the credentials associated with a request will vary dependingon the nature of the request. For example, the credentials may bewithout limitation, any combination of one or more of an email address,phone number, loyalty card number, device identifier, IP address, useridentifier, system identifier, biometric data, and so forth. In general,the credentials may include any of the contextual transaction data 1345discussed in connection with the embodiment of FIG. 13A, to the extentthat such contextual transaction data can be used to directly orindirectly, fully or partially identify a consumer.

The associated contextual transaction data or metadata may include alist of one or more items, such as shopping cart items or an item forwhich the requestor has recently accessed information. The associatedcontextual transaction data or metadata may include any other trackedbehaviors, including recent location(s) of the consumer, applications orwebsites recently accessed on a device from which the request was sent,and other recent events that can be attributed to the consumer. Thecontextual transaction data or associated metadata may be includeddirectly in the request, or the request may include information such asa session identifier that would allow a server to locate suitablebehavioral information may be located in particular server-side logs orother records.

Block 3040 comprises determining that a first customer record and secondcustomer record match the same credential(s) included in the request. Inother words, the identity of the customer is ambiguous at this point.

Block 3050 comprises selecting a particular customer record, of thefirst and second customer records, based on comparing the metadataassociated with the request to information stored in or derived from thebehavioral logs. Thus, behavioral logs are used to resolve the consumerto a specific identity. For example, an offer server may differentiatebetween a husband and wife based on comparing items that they arecurrently interested in to items that they are historically interestedin. Or the offer server may differentiate between the husband and wifebased on comparing historical device usage and/or location patterns torecent behavioral data.

Block 3060 comprises responding to the request based on customer accessdata associated with the selected particular customer record.

In various embodiments, the approach described in connection with theembodiment of FIG. 30 may be used to map a set of ambiguous consumercredential information that potentially relate to two or more consumerrecords to a single consumer record, and therefore uniquely identify oneconsumer with a certain degree of confidence. For example, if a largerfamily is associated with a single phone number, or if a group ofemployees of a company are all associated with a single customer IDnumber, a particular individual may be uniquely identified with asufficiently high degree of confidence based on contextual transactiondata and historical transaction records corresponding to those familymembers, or respectively, employees.

In one embodiment, even if a particular person is identified based on aset of ambiguous consumer credential information that potentially relateto two or more consumer records, the transaction conducted with thatperson may nevertheless be customized based on a different consumerrecord profile (i.e., a consumer record that is not associated with thatperson). For example, in one embodiment, if a husband and wife are usingthe same phone number or customer loyalty identifier at a retailer, andif the husband is identified as the person most likely making atransaction at a particular time, the husband may still be issued anoffer that would otherwise be available only to the wife (e.g., an offerthat is associated with the consumer record of the wife, an offer for aproduct that is normally purchased by the wife, etc.).

Many of the systems and methods described herein provide useful resultseven without the specific resolution techniques described above. Hence,the phrase “resolve a consumer entity” and like phrases as used hereinshould be understood to refer any of the resolution techniques describedabove, or to any other suitable technique for determining the identityof a consumer.

In an embodiment, some retailers may not keep or may decline to uploadconsumer records. Some or all of the retailers' transactions maynonetheless be resolved to specific customer records based on comparinginformation in the contextual transaction data or other transaction logto information in master customer records that was provided by retailersor other entities besides the retailer at which the transactionoccurred.

3.5. Offer Targeting

FIG. 23 illustrates a flow 2300 for targeting offers to specificconsumer entities, according to an embodiment. In various embodiments,the flow 2300 may illustrate in whole or in part the operation of theembodiments discussed in connection with FIGS. 15 and 16.

Block 2310 comprises storing event data describing a plurality ofevents. The events comprise at least a plurality of transactions and aplurality of web requests. However, a variety of other events may alsobe described, including offer redemptions, offer activations, visits byvarious consumers to specific locations, accessing certain smartphoneapplications, accessing a shopping list, ATM withdrawals, flights,prescriptions, and so forth. The event data may take a variety of forms,including collections of logs. For instance, the event data may compriseweb logs and transaction logs. Or the event data may comprise a singlecollection of normalized events, in which some event records representtransactions and other event records represent web requests. In anembodiment, some or all events are detected by parsing web logs ortransaction logs. In one embodiment, these events may be the eventsdiscussed in connection with the embodiment of FIG. 16. In oneembodiment, a data processing system, possibly operated by an offerdistributor, is adapted to select an offer from a plurality of offersbased on one or more such events.

The events may have been received from a variety of different sources,including consumer devices and retailers. The offer distributor maydeploy any number of event handlers to receive, process, and store theevents. For example, an offer server may be responsible for handling anyand all types of events, or one or more other servers or components maybe responsible for handling various aspects of the events. System 1600illustrates an example system for receiving and storing events, but avariety of alternative systems may be utilized.

There may be different types of event records for different types of webrequests. For example, one type of web request event may be a visit to amanufacturer's website, another type of web request event may be addingan item to an online shopping cart, another type of web request eventmay be viewing or activating an offer on an offer distributor's website,another type of web request event may be viewing a digital receipt,another type of web request event may be accessing a shopping listthrough a smartphone application, another type of web request event maybe a social networking message to a manufacturer or that references aproduct from the manufacturer, and so forth.

In an embodiment, multiple discrete events may be derived from a singlereceived event. For example, related purchase events for each itempurchased in a transaction may be derived from a transaction eventinvolving the multiple products. In an embodiment, certain complexevents may also be generated based on the received events. A complexevent is a plurality of received events that, to simplify targeted eventrecognition, have been combined based on their respective eventinformation and/or their resolved consumer entity. For example, multipledifferent transaction events might be used to generate a complex eventthat represents the purchases of multiple items within a certain timeperiod by a particular consumer. Or a series of location events that arecorrelated to a certain consumer entity may be used to generate acomplex event to represent a grocery shopping trip.

Block 2315 comprises storing target definition data describing aplurality of target contexts. For example, a context may include datasuch as demographic information about a consumer entity on whose behalfa request was likely made, a location associated with a request,information about a retailer associated with a request, pasttransactional and/or offer-related actions taken by the consumer entity,items in a shopping list or shopping cart belonging to the consumerentity, the time and/or day when the request was made, and so forth. Inone embodiment, these contexts may be the contexts discussed inconnection with the embodiments of FIGS. 15 and 16. In one embodiment, adata processing system, possibly operated by an offer distributor, isadapted to select an offer from a plurality of offers based on one ormore such target contexts.

Each context may be a set of one or more events that occur within aspecific time frame or sequence. Contexts may be arbitrarily simple orcomplex. For example, one context may be a purchase of a certain itemwithin a day of consumer opening a shopping list application. As anotherexample, a context may be a visit to an ATM machine within a few hoursprior to a football game by a 25-30 year old male who has purchasedtickets for the game. The contexts may be defined by offer providers,offer distributors, and/or automated processes that evaluate the eventdata for correlations, as described in other sections.

In an embodiment, a targeted context is a consumer that has purchased aproduct x in a last period of time. The purchase event is derived from atransaction at a first retailer. A second retailer, different from thefirst retailer, associates the targeted context with its own offer. Inan embodiment, the targeted context is a consumer, in a particularlocation, opening a smartphone application for managing coupons orshopping lists.

In various embodiments, a targeted context may be, or may includehistorical transaction records and/or contextual transaction dataretrieved from a memory or received from a remote retailer or otherentity, such as the historical transaction records and contextualtransaction data 1345 discussed in connection with the embodiments ofFIG. 13A or FIG. 15. In one embodiment, a data processing system,possibly operated by an offer distributor, is adapted to select an offerfrom a plurality of offers based on one or more historical transactionrecords and/or contextual transaction data.

Block 2320 comprises storing targeted offer data describing a pluralityof targeted offers. Each particular offer of the plurality of targetedoffers is associated with one or more particular target contexts, of theplurality of target contexts, to which the particular offer is targeted.For example, when an offer provider defines an offer using offercreation techniques such as described herein, the offer provider may begiven an option to link the offer to one or more of the target contexts.Additionally, or alternatively, the offer provider may be given theopportunity to define on or more new target contexts to which the offeris to be linked. In one embodiment, the offer distributor may charge anincreased fee for this service. In another embodiment, the offerprovider may associate a potentially different bid amount that the offerprovider is willing to pay for targeting an offer with each specificcontext to which an offer is targeted. The offer distributor may lateruse the bid as a factor in determining which offer to target to acontext.

Block 2330 comprises, based on the event data, correlating particularevents of the plurality of events to particular consumer records. Thecorrelation comprises resolving credentials associated with theparticular events to particular consumer entities, using any suitabletechnique. For example, a web-based event may include a deviceidentifier and/or consumer name that is resolvable to a particularconsumer entity. As another example, a transaction event may include aloyalty card number, credit card number, and/or line item details thatmay be resolved to a particular consumer entity. In an embodiment, forthe purposes of targeting offers, credentials that are ambiguous orotherwise resolve to a group of consumer entities with a certain degreeof confidence, may be correlated to each member of the group. In anembodiment, correlating comprises determining probabilities that anevent reflects activity by each of a plurality of consumers, andselecting a first consumer record because the first consumer recorddescribes the consumer having the highest probability.

In an embodiment, correlations may be reevaluated on an ongoing basis.For instance, correlations may be reevaluated whenever consumer recordsare updated, or on a periodic basis. In an embodiment, to reduce systemresource consumption, only events that could possibly match a definedtarget, or events that are used for reporting or other purposes, areactually correlated to a consumer entity.

Block 2340 comprises receiving, over a network, a request indicating afirst event. For example, an event handler may receive a new event likethose described with respect to block 2310.

Block 2350 comprises correlating the first event to at least a firstconsumer record, in the same manner as described above with respect toblock 2330.

Block 2360 comprises, based at least on one or more events, other thanthe first event, that have been correlated to the first consumer record,identifying a context for the first event. For example, the first eventmay form a complex event in concert with the other event(s) that werecorrelated to the consumer entity, such as a complex event for adding acertain item to a shopping list within a certain amount of time ofpurchasing another item or visiting a certain website. The context mayfurther include other information, such as demographic information forthe consumer entity to whom the first event was resolved. In fact, inanother embodiment, the context is determined based only on the firstevent along with the demographic information for the consumer entity.For example, one context might represent a web view of an offer by afemale of a certain age.

Block 2370 comprises matching the identified context to at least a firsttarget context of the plurality of target contexts stored in block 2315.It is possible that the identified context will match several targetcontexts. For example, one offer may target persons who purchased item Xwithin 72 hours, and another offer may target persons who purchased itemX at store A. If the identified context is purchasing item X at store Awithin the last 24 hours, both target contexts would match.

Block 2380 comprises selecting one or more offers, of the plurality ofoffers, that are associated with the first target context or any othertarget context matched in block 2370. The selecting may be performedbased on the targeted offer data stored in block 2320. In someembodiments, providers are free to associate and/or disassociate theiroffers with any target contexts for which they wish to pay.Consequently, multiple offers may at times be associated with the sametarget context. All of these offers may be selected, one or more offersmay be selected from these offers randomly, or one or more offers may beselected from these offers based on a variety of ranking criteria and/orrules. For example, a set of offers may be selected based on a revenueper targeted impression metric. Such a metric may take intoconsideration not only what each provider is willing to pay thedistributor for presenting the targeted offer, but also the opportunitycost associated with not presenting other offers instead, given factorssuch as distribution limits, expiration dates, and the likelihood of aspecific consumer entity actually activating the offer. As anotherexample, a set of offers may be selected based on a universal scoringfunction, as described herein. As another example, if an offer isassociated with multiple matching target contexts, the offer may beranked more highly. In an embodiment, it is also possible that, at anygiven time, some of the target contexts may not be associated with anyoffers.

Block 2390 comprises providing data describing the one or more offers toone or more devices operated by the correlated consumer entity inresponse to the request. Any suitable offer distribution technique maybe used for providing the information. In an embodiment block 2390occurs responsive to a request for a receipt for a particulartransaction. In an embodiment, the offer information in block 2390 maybe provided to a device that did not necessarily trigger or send thefirst event. In an embodiment, rather than provide information about atargeted offer to a consumer, the targeted offer may be activatedautomatically for the correlated consumer entity.

Flow 2300 illustrates but one example flow for targeting offers. Otherflows may feature additional or fewer elements, in potentially varyingorders. For example, another method for targeting offers comprisesmaintaining defined targets, receiving events, matching the events todefined targets, identifying a set of mapped offers that corresponds tothe matched targets, ranking the offers, and providing information aboutthe offers to a consumer. A variety of other suitable techniques arealso described elsewhere in this application.

Contextualized Events

In an embodiment, to assist in recognizing targeted event more rapidly,various contextualized events may also be generated. A contextualizedevent is an event, which may be simple or complex, that is generated tomatch a target context. The contextualized event represents, in essence,a predetermined context per 2360.

In an embodiment, a filtered set of events is passed to an eventcontextualizer. The filtered events may be passed as they are received,or during a subsequent analysis stage. For example, only those eventsthat could possibly form part of a match to a target definition arepassed to the event contextualizer. The event contextualizer examinesother events and information associated with the consumer entity towhich each filtered event has been correlated to determine if, in viewof the filtered event, the conditions of any defined target have beenmet. If the conditions of a target have been met, a contextualized eventis generated and stored for the consumer entity. A targeted offerselection process may then consider the contextualized event whenproviding targeted offers. For example, the targeted offer selectioncomponent may select a targeted offer based on the most recent or mostcommon contextualized event.

In an embodiment, to further speed up the analysis of events, the eventcontextualizer may maintain consumer context data that tracks a “state”of each consumer entity. The consumer context data indicates events thatmay form a match to a defined target in the future if a certain type ofevent is received. The consumer context data may comprise one or morestate machines or other appropriate data structures for tracking suchinformation. For example, if a defined target requires the purchase ofmilk and cookies within a 24 hour time span, the consumer context datamay indicate whether a transaction event has been received that showsthe purchase of one of these two items within the last 24 hours.

3.6. Offer Recommendations

In addition to, or instead of, presenting consumers with specificallytargeted offers, an offer server may also present consumers withrecommended offers that have not been specifically targeted to consumerevents. Any suitable recommendation engine may be used. Examples ofsuitable recommendation techniques are described in the referencedapplications. Additional offer recommendation techniques are describedin, for example, U.S. Ser. No. 13/612,848, the contents of which arehereby incorporated by reference for all purposes as if set forth intheir entirety herein.

Offers may be scored within a recommendation engine using scoringfunctions dependent upon any of a variety of signals, including metricsderived from transaction data, offer tracking data, offer data itself,and consumer behavioral logs. Different scoring functions may weighsignals differently in accordance with different objectives. Forexample, some scoring functions may be optimized to perform well withrespect to a metric that is favorable to an offer distributor, such asincreasing revenue per impression, revenue per redemption rate or otheroffer-related revenue, while other scoring functions may be optimized toperform well with respect to metrics that are favorable to a consumer,such as increasing an offer discount per consumer, while yet otherscoring functions may be optimized to perform well with respect tometrics that are favorable to a retailer or offer provider, such asprofit per impression. Different scoring functions may be used fordifferent contexts—for example, one scoring function may be used for aconsumer on a mobile device that is within the vicinity of a certainstore, while another scoring function may be used for a consumerbrowsing receipt data at home.

FIG. 24 illustrates an example flow 2400 for recommending offers,according to an embodiment. Block 2410 comprises storing offer datadescribing a plurality of offers, as described in other sections.

Block 2420 comprises identifying a plurality of collections of itemsets.An itemset is a set of two or more items. Within the context of theseitemsets, the term items may refer to products, services, and/or offers.The collections may include, for example, at least a first collection ofitemsets derived from transaction logs. Each itemset in the firstcollection comprises items indicated by the transaction logs as havingbeen purchased or used together. The collections may further or insteadinclude, for example, a second collection of itemsets derived from logsin one or more of: offer activation logs, offer redemption logs, oroffer impression logs. Each itemset in the second collection comprisesitems that appear together within a same one of the offer activationlogs, offer redemption logs, or offer impression logs. In an embodiment,each log in a collection is specific to a transaction. In an embodiment,each log in a collection may span multiple transactions, but be specificto a particular customer record.

In general, in various embodiments, a recommended offer may be ranked,identified, selected or otherwise analyzed based on a set ofrecommendation reference data. In various embodiments, therecommendation reference data may include virtually any type of datathat can be used as a basis for recommending an offer. In oneembodiment, the recommendation reference data includes contextualtransaction data received directly or indirectly from a retailer orother terminal that is facilitating a consumer electronic transaction,such as the contextual transaction data 1345 discussed in connectionwith the embodiments of FIG. 13A and FIG. 27. In one embodiment, therecommendation reference data includes historical transaction recordsretrieved from a memory or received from a remote retailer or otherentity, such as the historical transaction records discussed inconnection with the embodiment of FIG. 13A or FIG. 27. In variousembodiments, one or more of the items included in itemsets discussed inconnection with the embodiment of FIG. 24 may be included in, or derivedfrom, contextual transaction data and/or historical transaction records,or from any other suitable recommendation reference data.

While there may in fact be any number of different itemsets, in oneembodiment, there are at least six collections of itemsets, containingco-occurring items found in the following types of data: transactionlogs, shopping lists, web clickstreams for particular consumer entities,offer clickstreams for particular consumer entities, offer activationlogs for particular consumer entities, and offer redemption logs forparticular consumer entities. Depending on the embodiment, an itemsetderived from the last three collections may comprise offers themselves,or one or more offers in the itemset may be replaced with products orservices that are eligible for the respective offers. Other embodimentsmay feature various combinations of these six collections, and/or othercollection types. In an embodiment, the combination of collections usedvaries depending on context. In an embodiment, the collections may befiltered for demographic groups to which the consumer may belong. Forexample, the collections may be different for consumers in differentregions, of different ages, or in different social networking groups.

Block 2430 comprises, for each different collection, generatingassociations between pairs of items that co-occur within the itemsets.For example, if a single transaction involved products A, B, and C, thefollowing associations would be established: (A,B), (B,C), (A,C). In oneembodiment, one association may be counted for each possible combinationof items, no matter how often they co-occur within the collection. In anembodiment, block 2430 may be performed as part of a step of generatingassociations between each possible pair of items in a collection,regardless of whether those items co-occur in any single itemset.

Block 2435 comprises, for each different collection, calculatingassociation scores for one or more of the associations. The associationscores reflect an actual or estimated frequency of co-occurrence of thedifferent items within the association, relative to the collection.Association scores may be universal, specific to a social or demographicgroup to which a consumer belongs, or specific to a consumer.Association scores may be computed for all associations in advance ofrequests for recommendations, or may be calculated as needed in theblocks below. Examples of associations and association scores aredescribed in subsequent sections. In a general embodiment, virtually anyassociation may be made between two or more items, whether or not theybelong to the same the collection, and whether or not they co-occur atany time, and the algorithms for computing association scores may bedeveloped accordingly.

Block 2440 comprises receiving a request for offer recommendations. Therequest is associated with one or more items. For example, the requestmay be associated with items in a shopping list or in a receipt. Therequest may be from an entity seeking to embed offer recommendationswith a same presentation as the shopping list or receipt, or the requestmay simply be associated with the shopping list or receipt because therequest is within a same time period as the creation of the shoppinglist or the transaction for which the receipt was generated. Anassociation between a request and one or more items may also exist for avariety of other reasons. For example, a consumer's device may havescanned a barcode or visited a web page for an item prior to sending therequest.

Block 2445 comprises, for each different collection, matching the one ormore items associated with the request to particular associations withinthe collection. The matching may comprise locating associations thatinclude one or more of the items, locating associations that include oneor more similar items, and/or locating associations that include anoffer for the one or more items.

Block 2450 comprises, for each different collection, identifying a setof related items based on the matched associations. The related itemsare, in essence, items predicted to be of possible interest to theconsumer based on items for which the consumer has already indicated aninterest. In an embodiment, related items are identified only fromassociations having association scores above a threshold. In anembodiment, only a predefined number of related items belonging toassociations with the highest association scores are identified in eachcollection. In an embodiment, the related items include any item in amatched association. Depending on the embodiment and/or business rules,the related items may also include the one or more items associated withthe request of block 2440.

Block 2460 comprises merging the sets of related items, so that there isone set of related items regardless of the number of collections fromwhich the related items are obtained. Hence, the merged set may includeone or more items found in different sets of related items fromdifferent collections. Block 2460 is optional in some embodiments, wherethe recommendation engine has been asked to generate separate sets ofrecommendations for each collection.

Block 2470 comprises ranking the items in the merged set based at leastin part on the association scores. For example, an aggregate score maybe calculated for a related item based on a function of the associationscores, in each collection, for the associations based upon which therelated items had been selected. In an embodiment, if a particularcollection contains no association between the related item and aparticular item associated with the request, then the association scorefor that particular item in that particular collection is deemed to bezero.

The function may weigh the association scores in each collectiondifferently. Each collection may be assigned a global weight, or acontext-specific weight. For example, one collection may be weightedmore highly when a consumer is at home, while another collection may beweighted more highly if the consumer is out shopping. As anotherexample, each collection may have a different weight for different typesof individuals. The function may further weight association scoresdifferently based on how closely an item from block 2430 matches anassociation and/or other factors. For example, some items associatedwith the request may be deemed more important because of previousconsumer transactions and other historical behavior.

In an embodiment, the items may additionally or instead be ranked by auniversal scoring function, as described in other sections. For example,the aggregate association scores may also be a function of a universalscore.

Block 2480 comprises selecting a set of offers to recommend based on theranked items in the merged set. For example, offer(s) for a certainnumber of the highest ranked items may be returned by default, or therequest may have specified a number of offers to return. Or, only thoseoffers for items having above a threshold score are returned.

Offers may be identified for the items using any suitable technique. Forexample, block 2480 may comprise looking up which offer(s) areassociated with an item and, if requested by the provider, applyingbusiness rules to determine which of the offer(s) associated with theitem should be returned. As another example, offer-to-item associationscores may be used to determine which offer to return. In an embodiment,some or all of the related items in the associations are offers asopposed to products or services. If any items in the set of ranked itemsare offers, then selecting offers for those items simply comprisesselecting those items.

Flow 2400 is but one example technique for identifying offers torecommend to a consumer. Other techniques may comprise fewer oradditional elements, in potentially varying orders. For example, in anembodiment, items may further include events. Thus, various collectionsmay produce associations between offers, products, services, andconsumer activities described in various behavioral logs. The request ofblock 2440 may thus be associated with events instead of or in additionto items. Another technique simply involves generating recommendationsbased on a collection of itemsets that indicates which offers arefrequently redeemed together, or by the same consumer within a shortspace of time.

In some embodiments, the data involved in the recommendation process mayinclude customer demographics and transaction data, for customerclustering and macro-personalization or recommendations to clustersbased thereon, and/or for micro-personalization tailoringrecommendations to users having very similar behavior usingcollaborative filtering techniques such as association scoring.Additional considerations based on the transaction data may include atime-effects component to weight recommendations based on seasonalityand/or recency, and a predictive filtering component to anticipatefuture purchases and interests for uses based on historical purchases,using, for example, hidden Markov models. The data used in therecommendation process may further include product hierarchies, productattributes, inventory levels, and so forth. Business rules may beapplied to the recommendations. A testing platform uses feedback fromactual redemptions, activations, and/or purchases to assess andfine-tune the weights associated with the various data inputs.

In an embodiment, due to the computational cost of calculatingrecommendations in real-time, a ranked list of offer recommendations iscomputed for a consumer on a periodic basis. For example, such a rankedlist may be calculated each night. Based on events that have happenedsince the list was last computed, delta changes may be detected inranking calculations, and the ranked list may be adjusted in real-time.In an embodiment, the ranked list is nonetheless calculated from scratchfor some or all consumers on demand, rather than on a periodic basis.

Association Scores

In an embodiment, one recommendation technique involves calculatingassociation scores between items of interest to a consumer and offers orother items. Association scores, calculated by association scoringfunctions such as described herein (not to be confused with offerscoring functions), quantify the correlation between two of moreelements. One category of association scores is item-to-item correlationscores, also referred to herein as (item_(i),item_(j)) associationscores. The (item_(i),item_(j)) association scores indicate how likelyit is that a consumer that is interested in item; is also interested initem_(j). Different association scores may be a function of differenttype(s) of interest-indicating events. For example, separate associationscores may be calculated for items that are frequently clicked on by thesame consumer, items that are frequently purchased together, items thatare frequently purchased by the same consumer regardless of when theyare purchased, and so forth. If a consumer has recently expressed aninterest in item, various (item_(i),item_(j)) association scores maythen be used as input to an offer scoring function for an offer relatedto item_(i).

Another possible category of association score is offer-to-itemcorrelation scores, also referred to herein as (offer_(i),item_(j))association scores. The (offer_(i),item_(j)) association scores aresimilar to the (item_(i),item_(j)) association scores, except that theyindicate how likely it is that a consumer who is interested in item_(j)is also interested in offer_(i). Thus, for example, if a consumer has anitem_(s) in the consumer's shopping list, or if the item_(s) iscorrelated to another item in the consumer's shopping list, an(offer_(i),item_(j)) association score may be an input into an offerscoring function for offer_(i).

A similar category of association scores involves per consumercorrelations (also called a consumer-centric correlation score), denotedherein as (consumer_(i),offer_(j),item_(k)) association scores. Theseassociation scores measure how likely it is that a specificconsumer—typically the consumer for which a recommendation is beingcalculated, or a consumer with similar characteristics—will beinterested in both offer_(j) and item_(k).

In an embodiment, association scores may also quantify correlationsbetween items and events (an item-to-event correlation score), eventsand events (an event-to-event correlation score), consumers and events(a consumer-to-event correlation score), and various other permutationsthereof. In an embodiment, items may be recommended in addition tooffers. For example, the offer distributor may suggest adding items to ashopping list based on previous transaction data, other consumers'interests, and/or current items in a shopping list.

In one embodiment, the scores correspond to an actual frequency ofco-occurrence. In another embodiment, co-occurrence may be estimated byusing a scoring function learned from a training subset of eachcollection. The scoring function may be optimized for differentobjective functions, such as revenue per impression, retailer profit,and so forth. Association scores may further be based on signals otherthan frequency of co-occurrence, including, without limitation,location, purchasing trends, and consumer demographics.

Universal Scoring

In some embodiments, any process of ranking offers may be based in wholeor in part upon a universal scoring mechanism. The universal scoringmechanism is optimized to compute a universal score for each offer thatreflects one or more of estimated revenue per offer activation, revenueper offer impression, or revenue per offer redemption. Revenue refers toan amount of compensation received by one or more of: the offerdistributor, one or more retailers, the consumer, or the offer provider.The universal scores may be global for all consumers, relative to aparticular consumer, or relative to a group of consumers. In anembodiment, the universal scores estimate revenue in a manner that isotherwise divorced from the context of a request, with the possibleexception of artificially boosted scores to accommodate sponsorships ortargeted offers. Thus, at any given time, the universal score for anoffer is the same for all requests for recommendations by the sameconsumer(s), regardless of the context of those requests.

FIG. 25 depicts an example flow 2500 for generating a recommendationbased on a universal scoring mechanism, according to an embodiment.Block 2510 comprises storing offer data describing a plurality ofoffers, as described in other sections. Block 2520 comprises identifyinga collection of itemsets, each itemset of the itemsets being a set ofitems that appear together in a particular context. For example, block2520 may comprise identifying one or more of the collections describedabove with respect to block 2420. Block 2525 comprises receiving arequest for offer recommendations, the request associated with one ormore items, as described with respect to block 2440. Block 2530comprises generating associations between pairs of items that co-occurwithin the itemsets, as described with respect to block 2430. Block 2535comprises calculating association scores for one or more of theassociations, as described with respect to block 2435. Block 2540comprises receiving a request for offer recommendations, as describedabove with respect to block 2440. Block 2545 comprises matching the oneor more items associated with the request to particular associationswithin the collection, as described with respect to block 2445. Block2550 comprises identifying a set of related items based on the matchedparticular associations, as described with respect to block 2450.

Block 2560 comprises identifying offers associated with items in the setof related items. Offers may be identified for the items using anysuitable technique. For example, block 2480 may comprise looking upwhich offer(s) are associated with an item and, if requested by theprovider, applying business rules to determine which of the offer(s)associated with the item should be identified. As another example,offer-to-item association scores may be used to determine which offer toidentify for an item. In an embodiment, some or all of the related itemsin the associations are offers as opposed to products or services. Ifany items in the set of ranked items are offers, then selecting offersfor those items simply comprises selecting those items.

Block 2570 comprises calculating universal scores for the identifiedoffers. The universal score for each offer is based at least in part ona measure of revenue associated with activation or recommendation of theoffer. The universal scores may be calculated when the offers areidentified, or the universal scores may have already been calculated inadvance. For example, universal scores may be calculated for all offersbased on input signal(s) on a nightly or hourly basis, and then updatedas needed to reflect delta changes to the signal(s).

In an embodiment, calculating the universal score comprises comparingthe historical performance of an offer to average offer performanceacross a plurality of offers. In an embodiment, the universal score is afunction, at least in part, of one or more of the activations,impressions, or redemptions for an offer. In an embodiment, theuniversal score is based in part on a “burn rate” that ensures that anoffer is distributed at a consistent rate throughout a campaign, so thatthe total number of offer impressions specified by the provider are notexhausted too quickly. Such a burn rate may consider, for instance, theperiod that the offer has been active, the remaining period an offerwill be active, and the number of impressions that have thus far beenincurred. The burn rate may thus be based on the start date of theoffer, the initial inventory of impressions, activations, and/orredemptions that the provider made available for the offer, the enddate, the revenue per impression, activation, and/or redemption, and thetotal number of impressions, activations, and/or redemptions thus far.Further examples of universal scores are described in subsequentsections.

In various embodiments, one or more universal scores may be computedbased on a various types of data or metrics, including based on ahistorical or projected impact of the offer on sales of an item, ahistorical or projected offer redemption rate, a historical or projectedprofit per offer impression, a historical or projected profit margin, ahistorical or projected offer volume (e.g., the total number of offeractivations, offer impressions, offer redemptions and/or products sold),a historical or projected offer yield (e.g., a total profit figureassociated with an offer after taking into account the total number ofsold products corresponding to that offer, offer activations, offerimpressions and/or offer redemptions), a historical trend in offers madeavailable by the offer provider, a historical or projected profit marginfor the offer distributor and/or for the offer provider, a historical orprojected impact of the offer on other offers, a historical or projectedimpact of the offer on consumer behavior, etc.

In an embodiment, a provider may pay to apply a “sponsorship boost” to auniversal score to artificially increase the calculated score. Thesponsorship may be general, or the sponsorship may be targeted, per thetargeting techniques described herein. The boost may take the form of anadded signal to a universal scoring function, an additional weight tothe universal scoring function, and so forth. In some embodiments, thesponsorship boost is designed to artificially raise the universal scoreto score that is unattainable without a sponsorship boost, thus ensuringthat a sponsored/targeted offer is the highest returned offer. In otherembodiments, the sponsorship boost does not necessarily raise an offer'sscore higher than scores for non-sponsored offers. In an embodiment,when multiple targeted offers apply to a request, only a single offer ora handful of offers actually receive the sponsorship boost. The offersto which the sponsorship boost is applied may be selected at random,selected based on the association scores, or selected based on how mucheach provider has agreed to pay for the sponsorship boost.

Block 2580 comprises ranking the identified offers based at least inpart on the universal scores and the association scores. In other words,in response to any given request for a recommendation, the offers areranked based not only on a measure of how much revenue therecommendation is predicted to bring to a particular party, but also ameasure of how much of an association there is between the request andthe offers. For example, a universal ranking mechanism may comprisesorting each offer by the product of the offer's universal score and theassociation score, or average association score, of the item(s) basedupon which the offer was identified in block 2560. Other universalranking mechanisms may involve other functions of the universal scoresand association scores.

In various embodiments, offers may be ranked based on one or moreuniversal scores determined for a particular consumer, or for aplurality of consumers. In various embodiments, offers may be rankedbased on one or more universal scores determined for a set of consumers,for a set of retailers, for a set of offer providers, or for acombination of one or more consumers, retailers and/or providers.

Block 2590 comprises selecting a set of offers to recommend based on theranked offers. For example, offer(s) for a certain number of the highestranked items may be returned by default, or the request may havespecified a number of offers to return. Or, only those offers for itemshaving above a threshold score are returned.

Flow 2500 is but one example technique for utilizing universal scores torecommend offers. Other techniques may comprise fewer or additionalelements, in potentially varying orders. For example, in anothertechnique, block 2580 involves a ranking function of the universalscores, but not the association scores.

Integration with Offer Targeting

In an embodiment, offer targeting and offer recommendation techniquesare practiced separately from each other within the same system.Targeted offer data may be kept separate from recommended offer data, orall offers may be both targetable and recommendable, depending onparameters defined by the offer provider. However, the offer serverdelivers the targeted offers in a separate channel from the recommendedoffers, such as via different interfaces or in different sections of awebsite.

In an embodiment, offer targeting is integrated with offerrecommendation, in that both targeted offers and recommended offers areranked using a universal scoring system, as described above. In anembodiment, targeted offers and recommended offers are still definedseparately. In another embodiment, there is no substantial difference. Asingle offer definition may include parameters describing how it is tobe recommended and how it is to be targeted. Universal scoring is, inessence, the vehicle for allowing the ability to “Sponsor” or “Boost”the value and priority of an offer, and finally one of the techniques bywhich an alternative recommendation (e.g. manual target) may beintegrated into the recommendation flow. In other words, offer providersmay pay for a higher universal score for certain targets.

FIG. 27 illustrates an example flow 2700 for integrating offerrecommendation and offer targeting within a single offer distributionsystem, according to an embodiment.

Block 2710 comprises receiving, via an offer definition interface at adata processing system (e.g., an offer server computer), offerdefinition data describing a plurality of offers. For example, differentoffer providers may create different offers for distribution via anoffer server using offer creation techniques such as described herein.

Block 2715 comprises storing target definition data describing aplurality of contexts under which requests to the offer server mayoccur. Block 2715 may be performed, for example, in similar manner toblock 2315.

Block 2720 comprises receiving, via the offer definition interface,target association data. The target association data associates eachparticular targeted offer, of a plurality of targeted offers in theplurality of offers, with particular target definition data in thetarget definition data. The particular target definition data describesone or more particular contexts to which the particular targeted offeris targeted. The particular target definition data may be separate fromthe terms of each offer. For example, when a provider creates an offer,or anytime thereafter, the provider may be given the opportunity toselect contexts the provider would like to target with the offer. In anembodiment, the provider further specifies a “bid” amount that theprovider wishes to pay the distributor for providing the offer in thespecified context.

Block 2730 receiving, at the offer definition server computer, from arequestor, a request associated with a request context. The request maybe any request to which an offer server will respond with offers. Forexample, block 2730 may comprise receiving a request for a receipt, or aweb page containing offers. The request may include one or morecredentials by which a consumer entity is resolved. A context may bederived for this consumer entity based on data mapped to that consumerentity, such as previous events related to the consumer entity,transaction data, location data, shopping lists, web logs, activitylogs, demographic information, and so forth. Additionally, or instead,the request may include similar information. In an embodiment, thecontext is specified explicitly by the requestor.

Block 2740 comprises matching the request context to at least aparticular context described in the target definition data. Block 2740may be performed in similar manner to block 2370.

Block 2750 comprises, based on the target association data, selecting,for inclusion in a response to the request, a targeted set of offers.The targeted set of offers is one or more offers, from the plurality oftargeted offers, that the target association data associates with theparticular context. Block 2750 may be performed in similar manner toblock 2380.

Block 2760 comprises selecting, for inclusion in the response to therequest, a recommended set of offers. The recommended set of offerscomprises offers, from the plurality of offers, that are ranked highlyby a recommendation engine, such as those described herein, with respectto the request context. The selection of recommended offers differs fromthe selection of targeted offers for at least the reason that therecommended offers are selected without taking into account the targetassociation data. That is, the recommended offers are selected forreasons other than whether or not an offer provider associated therecommended offers with the request context. In fact, the providers maynot have targeted the recommended offers to the request context at all.Rather, the recommended offers are offers that a recommendation has“learned” to be associated with the request context through variousmachine learning techniques, such as described herein.

In various embodiments, a recommended offer may be identified based oncontextual transaction data received directly or indirectly from aretailer or other terminal that is facilitating a consumer electronictransaction, such as the contextual transaction data 1345 discussed inconnection with the embodiment of FIG. 13A. In various embodiments,contextual transaction data may include any of a variety of informationrelated to one or more consumer transactions conducted within a facilityowned, controlled or operated by a retailer, including withoutlimitation basket-level transaction details such as universal productcodes and quantities purchased, total number of items purchased,transaction amounts, payment details (e.g., a credit card number, apayment identifier, a secure payment hash key), information about a dataprocessing system, logic module or facility where the transaction takesplace (e.g., terminal 1340 or store 1330), time, date, offers appliedduring the transactions, information relating to the customer conductingthe transaction (e.g., a name, a phone number, a pin number, a password,a code, a loyalty card number, other biometric or personalidentification data, etc.), RFID data, a device identifier, items thatwere purchased in a previous or concurrent transaction, a transactionnumber, and so forth.

In various embodiments, a recommended offer may be identified based onhistorical transaction records retrieved from a memory or received froma remote retailer or other entity, such as the historical transactionrecords discussed in connection with the embodiment of FIG. 13A.Historical transaction records may include various classes ofinformation that relate to users, transactions, vendors, paymentprocessing, and any other aspects of electronic or physical commerce. Asan example, historical transaction records may be, or may includecontextual transaction data that was generated in connection withprevious transactions. In various embodiments, historical transactionrecords may include any of a variety of information related to one ormore past consumer transactions conducted within a facility owned,controlled or operated by a retailer, including without limitationbasket-level transaction details such as universal product codes andquantities purchased, total number of items purchased, transactionamounts, payment details (e.g., a credit card number, a paymentidentifier, a secure payment hash key), information about a dataprocessing system, logic module or facility where the transaction takesplace (e.g., terminal 1340 or store 1330), time, date, offers appliedduring the transactions, information relating to the customer whoconducted the transaction (e.g., a name, a phone number, a pin number, apassword, a code, a loyalty card number, other biometric or personalidentification data, etc.), RFID data, a device identifier, items thatwere purchased in a previous, concurrent or subsequent transaction, atransaction number, and so forth.

In an embodiment, targeted offers differ from recommended offers in thatthe provider has specified different amounts to compensate thedistributor for targeted offers versus recommended offers. In anembodiment, recommended offers are associated with a flat offer fee,regardless of the context in which they are distributed, whereastargeted offers may have different fees for different target contexts.

Block 2770 comprises sending the response to the requestor, includinginformation about both the targeted set of offers and the recommendedset of offers. The information about the targeted offers and recommendedoffers may be organized within the response in any suitable manner. Forexample, there may be separate distribution channels within the responsefor recommendations and targeted offers. For instance, recommendedoffers may be presented in a section labeled “recommendations,” whereastargeted offers may be presented in a section labeled “you might alsolike.” Or, the targeted offers may be intermingled with therecommendations in a same distribution channel. The response may, insome embodiments, contain a variety of other information, such as areceipt, a report of aggregated transaction data, a shopping list, anonline shopping interface, a web page, and so forth. In an embodiment,the requestor will add the offer information to its own web page,containing other information such as described above.

Flow 2700 is but one example technique for integrating targeted offersand recommended offers. Other techniques may comprise fewer oradditional elements, in potentially varying orders. For example, therequest context includes a certain combination of events that occur in atimespan. Matching the request to a target context involves findingparticular context(s) that include the combination of events. Bycontrast, recommendation involves generating signals based on theevents, and inputting the signals into one or more scoring functions. Asanother example, in an embodiment, the targeted offers areauto-activated, per the techniques described herein, but the recommendedoffers are not.

3.7. Offer Creation

As described in other sections, potential offer providers may log intoan offer definition interface to define offers that they wish for anoffer distributor to distribute. Through the interface, the providersmay define any of a variety of offer terms, offer targets, and campaignparameters. In an embodiment, a distributor may simplify the process ofdefining offers by utilizing transaction data and historical offertracking data to propose offers, terms, targets, and/or campaignparameters to a provider. The distributor may propose the offers viaautomated emails and/or in various areas of the offer definitioninterface.

FIG. 28 illustrates a flow 2800 for proposing offers, terms, targets,and/or campaign parameters to a provider, according to an embodiment.Block 2810 comprises storing transaction data for a plurality ofconsumers from a plurality of different sources, as described in othersections. Block 2820 comprises correlating transaction data forparticular consumers to form transaction histories specific to each ofthe particular consumers, as also described in other sections.

In various embodiments, proposing offers, terms, targets, and/orcampaign parameters to a provider may be based on historical transactionrecords, contextual transaction data and/or offer data retrieved from amemory or received from a remote retailer or other entity, such as thehistorical transaction records, contextual transaction data 1345 and/oroffer data discussed in connection with the embodiments of FIG. 13A orFIG. 15. In one embodiment, a data processing system, possibly operatedby an offer distributor, is adapted to evaluate, rank and proposeselected offers, terms, targets, and/or campaign parameters byprocessing various historical transaction records, evaluating variousoffer data associated with the one or more offer providers, and/ortaking into consideration contextual transaction data received fromconsumer transactions that are taking place simultaneously, that aretaking place substantially simultaneously, or that took place recently.

Block 2830 comprises analyzing transaction histories and otherhistorical transaction records, contextual transaction data and/or offerdata to identify trends with respect to a set of products in thetransaction histories. A variety of trends may be identifiable from thetransaction data. For example, one type of trend indicates that during acertain time period, such as a day of the week, week of a year, orseason of the year, sales of a particular product occur more or lessfrequently. Another type of trend may involve correlating high salesvolumes for a particular product to external events, such as weatherevents or sporting events. Another type of trend may involve correlatingsales volumes to certain pre-defined target contexts, such as a targetdemographic living in a target location. Another type of trend mayinvolve correlating sales volumes to particular price points at whichthe product was sold at each of a plurality of different retailers. Theprice points may or may not consider whether any discount were appliedto the transactions.

Another trend type may involve identifying time periods in which aprovider has previously defined an offer for a product, and determininga pattern that the retailer appears to be following in making particularoffers available. Another trend type may involve analyzing thetransaction data in view of previous offers for a particular product toquantify a percentage change in the sales volume during previous offerperiods. The trend may further compare the cost of the previous offers,with respect to retailers, offer distributors and/or offer providers, tothe increase in sales volumes to arrive at a metric for how effective aprevious offer was. Another type of trend involves determining how manyconsumers use or redeem previous offers (e.g., activation or redemptionrates). Another trend type involves determining how successful previousoffers were in persuading particular consumers who have not previouslybought a product into purchasing the product. Another trend type mayinvolve determining how successful previous offers were in convincingparticular consumers to continue purchasing a product after the previousoffer is concluded. Another type of trend may involve correlating salesof one product to offers available for another product.

Trends may be global, or confined to pre-defined geographical areas.Trends may further or instead be specific to consumers whose profilesfit certain demographics. In an embodiment, trends may be identifiedusing a variety of types of analyses. For example, trends may discoveredusing certain machine learning techniques trained to identify variouscombinations of factors that produce results that are out of theordinary. As another example, characteristics of each of a plurality oftrend types may be enumerated in advance. Characteristics of a trend mayinclude, without limitation, particular groups of consumers, particularregions, particular lengths of time, correlations in time to certainevents, a particular volume of sales relative to average sales volumes,the existence of certain types of offers or marketing campaigns, and soforth. Various combinations of the characteristics may be analyzed tosee if trends develop. In an embodiment, various pre-defined trend typesare established. Transaction histories are analyzed to see if anypre-defined trend type does in fact exist. In an embodiment, each trendmay further include one or more metrics that quantify the strength ofthe trend. In an embodiment, a provider may in fact define certaintrends that the provider is looking for.

In an embodiment, trends are computed in advance of the following steps,and data describing the trends is stored so as to be readily availablein the following steps. In other embodiments, trends may be computeddynamically as a consumer selects a product for which to create anoffer.

Block 2840 comprises, based on the identified trends, generating offerdata describing a set of potential offers with respect to the set ofproducts. Identifying the potential offers may involve any variety ofconsiderations. For example, one offer may be proposed simply becausethe trends show that the provider frequently creates a certain type ofoffer at the beginning of each month. Another offer may be proposedbecause trend data shows that a related product performed well when asimilar offer was available, and/or at a similar price point. Forexample, a product database may associate products with similar productsusing categorical and/or other data. Offers for one product may be usedto gauge the effectiveness of offers for similar products, whether ornot the products are manufactured by the same entity.

Another offer may be proposed because trend data shows that an offer ishighly successful with respect to a category of products. The trend datamight also show the offer as highly successful for a certain context,such as for consumers who have purchased a product X within a timeframeT, or for consumers fitting a particular demographic who access a couponapplication at a certain time of day. The proposed offer may be thustargeted to the certain context. Examples of other target contexts arediscussed in connection with the embodiments of FIGS. 15 and 16. Anotheroffer may be proposed because transaction data shows that purchase of aproduct in one category of products is highly correlated with purchasesin another category of products. Thus, the provider may wish to offer adiscount on one product conditioned upon the purchase of anotherproduct.

Generating the offer data comprises determining terms and campaignparameters of the potential offer, such as the length of the offer, thediscount for an offer, the product(s) for which an offer should beeligible, the stores at which an offer may be used, the context(s) towhich an offer should be targeted, the number of offers to distribute,the number of offers to distribute per geographic area, and “bid”amount(s) that the provider is to pay for each offer distributed tocertain context(s). In an embodiment, the determination simply comprisesidentifying terms and parameters that a provider has previously used. Inan embodiment, the determination comprises predicting which terms and/orparameters will be best for a provider and proposing those terms and/orparameters. For example, based on frequency of purchase data, it may bepredicted that a particular combination of an offer start and offer enddate will be best for the provider, to the offer distributor, or to aretailer. Predictions are made based on trends identified for the sameterms/parameters in previous offers for the same or similar products.Predictions may furthermore be adjusted for trends identified withrespect to purchase histories for the same or similar products.

In an embodiment, each potential offer may be associated with one ormore metrics. For example, a potential offer may be associated with apredicted change in the volume of sales of one or more products inresponse to the potential offer. Or a potential offer may be associatedwith an overall offer effectiveness metric that predicts a bottom-lineimpact on revenue for the provider based on making the potential offer.For example, based on previous trends with respect to similar offersand/or similar products, an offer definition system may execute analgorithm to predict factors such as total expense to the provider andthe expected increase in sales over a certain time period. The certaintime period may include both during the offer and after the offer,depending on the embodiment. A predicted offer effectiveness metric maybe a function of these factors.

In an embodiment, because of the vast amount of transaction dataavailable to the transaction aggregation system, the offer distributormay be in a much better position to gauge the effectiveness of an offerthan the provider. For example, a predicted offer effectiveness metricmay take into consideration the impact of an offer on other productssold by the provider. The predicted offer effectiveness metric may alsotake into consideration consumer transaction histories to determine howlikely it is that an offer will actually make a difference in whether aconsumer buys a product. For example, the offer effectiveness metricshould take into consideration whether a consumer frequently buys aproduct even when no offer is available. In various embodiments, some orall of the determinations and/or actions involved in identifying andproposing an offer may be automatically performed by a data processingsystem associated with the offer distributor, without the directinvolvement of the offer provider. For example, an offer provider may ormay not know the criteria and algorithms used by an offer distributor toidentify, select and/or produce a recommended offer.

In an embodiment, predicted offer effectiveness metrics may be utilizedin determining whether to actually propose an offer to a provider. Forexample, only high scoring offers may be proposed, and/or offers may besorted by offer effectiveness metrics. In an embodiment, an offerdefinition system may create hundreds or thousands of potential offersbased on permutations of various offer terms and campaign parameters.The offer definition system may then test each potential offer againstthe offer effectiveness metric, to determine which potential offersscore highest. The offer definition system may then propose the highestscoring offer. Or, in an embodiment, the offer definition system mayonly propose an offer if the offer's effectiveness score is above athreshold value. The threshold value may, in an embodiment, beconfigured by the provider. In some embodiments, the offer definitionsystem need not necessarily create and test thousands of potentialoffers. Rather, various learning functions and models optimized for apredicted offer effectiveness metric may identify desirable offer termsand campaign parameters.

In an embodiment, the potential offers may be ranked and/or selectedbased on any or all of a predicted revenue per impression metric,predicted key performance index, or predicted retailer profit index.

Block 2850 comprises presenting, to an advertiser, an interfacedisplaying information about the set of potential offers. The advertisermay be the provider of the offer. In an embodiment, block 2850 isperformed in response to identifying potential offers in block 2840. Forexample, block 2850 may involve emailing proposed offers to a providerperiodically, or whenever high-scoring potential offers are identified.As another example, block 2840 and 2850 may be performed when a consumerinitially logs into an offer definition interface. The offer definitioninterface may feature a start screen or sidebar with proposed offers. Inan embodiment, the offer definition interface may further allow aconsumer to click on a proposed offer to modify terms or parameters ofthe proposed offer.

In an embodiment, blocks 2840 and 2850 are performed concurrently in aninteractive offer definition interface. A provider may log into theoffer definition interface and indicate that the provider wishes todefine an offer. The provider may enter one or more initial offer termsand/or campaign parameters, such as product(s) to which an offer willapply. Based on these offer terms and/or campaign parameters, the offerdefinition interface may display proposed terms and parameters for acomplete offer. The provider may accept the proposed offer, or may tweakproposed offer terms and parameters. In an embodiment, the offerdefinition interface is displayed alongside one or more various metricsof predicted effectiveness, which change as the provider tweaks termsand/or parameters. In an embodiment, the offer definition interfacefeatures interactive components allowing a consumer to drill-down intotransaction histories and offer histories, and/or to define their ownmetrics of predicted effectiveness.

Block 2860 comprises, responsive to displaying the interface, receivinga selection from the advertiser of one or more particular offers in theset of potential offers. For example, the provider may click on an “Addnow” link within an email to confirm that the provider wishes to createa proposed offer that was described in that email. Or, once a providerhas finished reviewing and/or modifying offer terms and campaignparameters for a proposed offer in an offer definition interface, theprovider may click on an interface control within offer definitioninterface to create the offer.

Block 2870 comprises adding particular offer data describing theselected one or more particular offers to a repository of offer data.That is, once a provider has selected to create a proposed offer, perblock 2860, the offer is added to an offer distributor's inventory ofavailable offers. Based on the repository of offer data, per block 2880,the offer distributor may then respond to requests from consumers toaccess the one or more particular offers, as described in othersections.

Flow 2800 is but one example flow for proposing offers to offerproviders. Other flows may comprise fewer or additional elements invarying arrangements. For example, in an embodiment, the method furthercomprises correlating purchases of different products, identifying pricepoints based on information about the price at which a product waspurchased, identifying terms of offers based on transaction frequencydata, and/or allowing an advertiser to modify a proposed offer.

3.8. Dynamic Offers

In an embodiment, an offer definition interface may allow a provider todefine a dynamic offer comprising one or more terms that vary accordingto the consumer who activated the offer. For example, a dynamic offermay allow a provider to dynamically adjust the price point that aconsumer effectively pays for an item based on the consumer's previoustransaction history.

FIG. 29 illustrates a flow 2900 for generating and/or utilizing dynamicoffers, according to an embodiment. Block 2910 comprises receivingvalues for non-dynamic terms of a dynamic offer. For example, a providermay intend for certain offer terms such as the start date, end date, andeligible products, to remain the same for all consumers. The providermay thus define static values for these terms. The attributes may bereceived via, for instance, an offer definition interface as describedherein.

Block 2920 comprises receiving a value selection scheme for a variableoffer attribute (e.g., a variable term) of a dynamic offer. For example,instead of entering a specific value for a particular term, the providermay select a control indicating that the value of the term should bevariable. Or, based on trend data, the offer definition interface maypropose that a value be made variable. The provider may define a valueselection scheme for the discount amount term of an offer, or any othersuitable term. In various embodiments, a value selection scheme may helpdefine a parameter or a range of parameters for one or more offerattributes. For instance, the provider may define different targetcontexts to which different values should apply. Or the provider maypropose a function of various consumer attributes, such as metricsrelated to purchasing or offer redemption histories, for calculating avalue. In an embodiment, a variable value is a function of thelikelihood that a consumer will purchase an item without an offer and/ora likelihood that a consumer will continue to purchase an item after theoffer expires. To simplify defining the value selection scheme, theoffer definition interface may propose one or more value selectionschemes. The offer definition interface may furthermore show the impactof the value selection scheme on different consumers and/or variouspredicted offer effectiveness metrics.

Block 2930 comprises generating a dynamic offer record including one ormore attributes corresponding to terms of the dynamic offer, theattributes including at least one variable offer attribute associatedwith the value selection scheme. Block 2940 comprises storing thedynamic offer record in a repository of offer data, such as describedherein. In one embodiment, a dynamic offer record is predefined and isretrieved from a memory or is received from a remote data processingsystem or logic module.

In various embodiments, attributes included in a dynamic offer recordmay include any aspect or characteristic of an offer, such as a discountamount, a duration for which the offer is valid, a set of products towhich the offer may apply, restrictions on impressions, activations orredemptions, restrictions on geographic applicability, appearance orcontent of the offer, and virtually any other offer attribute orparameter discussed in connection with various embodiments or otherwiseapplicable to electronic offers.

Block 2940 comprises identifying a particular consumer record inassociation with which the dynamic offer is to be distributed. Block2940 may occur as part of distributing an offer using any suitabledistribution technique described herein, including distributing an offerspecifically requested by a consumer, recommending an offer to aconsumer, and targeting an offer to a consumer.

In various embodiments, the consumer record may be, may include, or maybe included in a set of historical transaction records. Various examplesof historical transaction records that may relate to consumer recordsare discussed in connection with various embodiments, including theembodiments of FIGS. 13, 21, 30 and 34.

Some examples of historical transaction records that may relate toconsumers and that may be suitable for consideration in connection withdynamic offers include records obtained from consumer behavioral logs(e.g., transaction logs, event logs, offer tracking logs, locationtracking logs, shopping list logs).

Other examples of historical transaction records that may relate toconsumers and that may be suitable for consideration in connection withdynamic offers include, with respect to one or more electronictransactions that were conducted in the past by one or more consumers,information regarding a universal product code, a quantity of productpurchased, a number of items purchased, a transaction amount, at least aportion of a credit card number used, a payment identifier used, asecure payment hash key, a data processing system, a merchant orretailer facility, time or date when a transaction took place, one ormore offers activated or redeemed, customer name, phone number, pinnumber, password, code, loyalty card number, RFID data, a deviceidentifier, one or more items that were purchased in a previous orconcurrent transaction, or a transaction number.

Block 2950 comprises selecting a particular value for the variableattribute based on applying transaction data or demographic dataassociated with the particular consumer record to the value selectionscheme, thereby dynamically selecting at least one term of a customoffer for the particular consumer. For example, if the value selectionscheme defines different values for different categories of consumers,block 2950 comprises determining the category of the particularconsumer. Or, if the value selection scheme is a function of variousaggregated transaction data for the particular consumer, block 2950comprises computing the aggregated transaction data and then computingthe particular value based on the function of the aggregated transactiondata.

Block 2960 comprises, generating custom offer data describing a customoffer for the particular customer record that is created based on thedynamic offer record, using the selected value for the variable offerterm. The custom offer data may be a non-dynamic offer record, stored inthe same manner as any other offer in the offer repository. Or, thecustom offer data may be a temporary structure that is deleted after aperiod of time or if the consumer offer is ever redeemed. If multipleconsumers are provided the same custom offer, a single offer record mayexist for the multiple consumers.

In one embodiment, a data processing system is adapted to generate oneor more dynamic offers by processing a set of historical transactionrecords and a dynamic offer record that comprises a set of offerattributes corresponding to terms of the dynamic offer. One or more ofthe offer attributes may be modified based on at least a subset of thehistorical transaction records. In one embodiment, the data processingsystem modifies one or more such offer attributes based on a set ofhistorical transaction records, therefore producing a dynamic offer.Such a dynamic offer could also be construed as a customized offer inthe sense that the offer was customized based on a particular input.Examples of other inputs that could be used to customize an offer,therefore producing dynamic offers, include contextual transaction data,offer data, and target contexts. Examples and types of contextualtransaction data, offer data and target contexts are discussed herein inconnection with various figure embodiments.

In various embodiments, electronic dynamic offers may be generated inresponse to similar types of requests that are discussed herein inconnection with non-dynamic electronic offers. In various embodiments,electronic dynamic offers may be analyzed, ranked, recommended,distributed or otherwise processed and managed in ways similar to thosediscussed herein in connection with non-dynamic electronic offers.

Block 2940 comprises storing the dynamic offer record in a repository ofoffer data, such as described herein.

Block 2970 comprises presenting information about the custom offer,including the at least one dynamically selected term, in response to arequest associated with the particular consumer record. For example, thedynamic offer (which can be considered to be a customized offer) may berecommended to the consumer in a receipt, returned to the consumer in alist of offers that are responsive to a search, described in anotification message to the user that the dynamic offer has beenauto-activated for the consumer, or provided in any other distributionchannel described herein.

Block 2980 comprises receiving a request to access the custom offer inassociation with the particular consumer record. Block 2990 comprisesassociating the custom offer data with the particular consumer record.For example, blocks 2980 and 2990 may comprise activating the customoffer for the particular consumer using any activation techniquedescribed herein. Once the custom offer has been activated, the customoffer data becomes a permanent offer record, linked to the dynamicoffer. The custom offer is treated much like any other offer in theoffer repository, except that it cannot be activated by consumers otherthan those for whom the value selection scheme selects the same valuefor the variable term. Also, any applicable distribution limits arecounted against the dynamic offer record instead of the custom offerrecord. If the customer offer is auto-activated for the consumer, blocks2980-2990 may be optional.

Flow 2900 is but one example of techniques for utilizing custom offers.Other flows may include additional or fewer elements in potentiallyvarying arrangements. For example, in an embodiment, the custom offerrecord may be sent to a retailer and/or a clearinghouse to ensure thatthe dynamic offer is correctly applied to the consumer. In anembodiment, the method comprises varying a price depending on theconsumer, varying tied products depending on the consumer, or varyingthe length of an offer depending on the consumer.

In an embodiment, a dynamic offer includes an offer image that iscustomized or otherwise modified depending on a consumer. That is, theimage shown to entice a consumer to investigate an offer may bevariable. For example, both a product A and a product B may be eligiblefor an offer. Conventionally, a retailer must choose a single productimage to show to a consumer. Since a consumer often uses the imageassociated with an offer to identify which offers may be of interest tothe consumer, a consumer who may be interested in product A might notnotice the offer if the image shows product B. A dynamic offer record,by contrast, allows a provider to specify that the distributor shouldshow a picture of product A to a consumer who meets certain criteria,such as having purchased product A recently or having relativelyexpensive tastes, but show a picture of product B to another consumer.In other embodiments, a similar effect is achieved without a dynamicoffer record, as the retailer or distributor may dynamically selectwhich product image(s), from a database of images, to show for an offerbased on consumer data and other criteria.

3.9. Conducting a Transaction with Electronic Receipts

FIG. 3 illustrates a method flow 300 for conducting a transaction inwhich an electronic receipt, also referred to herein as a digitalreceipt, may be provided, according to an embodiment.

Block 310 comprises receiving input specifying one or more items forpurchase by a consumer and, optionally, one or more payment mechanisms.For example, the input may be received by a cash register or otherterminal at a checkout stand in a brick-and-mortar store, and/or aretail server, payment server, or other server to which such input hasbeen relayed. The input specifying the one or more items may involve,for instance, scanning Universal Product Code (“UPC”) symbols, detectingRFID or Near-Field Communication (“NFC”) tags, weighing products,entering item identifiers via a keyboard, selecting items via atouchpad, and so on. The input specifying the one or more paymentmechanisms may include, for instance, swiping a credit card through amagnetic reader, detecting an RFID or NFC tag, the tendering of cash ora credit card, a transfer of funds via a mobile payment application on amobile device, and so on.

Block 320 comprises performing, or causing the performance of, atransaction in which the specified one or more items are purchased,optionally using the one or more provided payment mechanisms. Forinstance, the entity receiving the input of block 310 may calculate atotal price for the transaction based on the one or more items, and thensend a request to one or more payment providers to transfer the relevantfunds to the retailer. Once the one or more payment providers haveresponded with an acknowledgment that the transfer has been approved,the entity may consider the transaction complete. As another example,the terminal may await confirmation from a cashier that appropriatepayment has been received, such as the cashier entering a sum of moneyor other tender that the consumer has provided the cashier. Once thetransaction is considered complete, the entity performing block 320 mayproceed, or instruct the terminal to proceed, with any of blocks330-380, depending on whether any of blocks 330-380 were performed priorto the completion of the transaction.

Block 330 comprises providing an interface configured to accept inputindicating a consumer identifier associated with the transaction. Forinstance, the interface may be a magnetic card scanner, an RFID or NFCreader, a touchscreen, a biometric scanner, a keypad, facial recognitionsoftware, and so forth. Depending on the environment, the consumeridentifier may comprise any of, for instance, a store loyalty cardnumber, a credit card number, an NFC or RFID tag, a hardware identifier,a phone number, a license number, biometric data, a consumer name, andso forth. In an embodiment, multiple interfaces capable of receivinginput identifying multiple types of identifiers may be provided.

The interface may be configured to accept the input indicating theconsumer identifier at different specific times relative to blocks310-320. For example, the interface may be configured to accept theinput immediately before payment, immediately before scanning items forpurchase, or upon completion of the transaction. The interface mayinstead be configured to accept the input at any range of times relativeto blocks 310-320, such as at any time before the consumer providespayment, or at any time up until a paper copy of a receipt is printed.In an embodiment, the input is received at any time during a window intime that can be uniquely tied to the transaction.

In an embodiment, the cashier and/or terminal prompt the consumer toprovide the input via the interface. In an embodiment, the cashierenters the input on behalf of the consumer. For example, the cashier mayinvite the consumer to provide an identifier such a store loyalty cardprior to receiving payment or even scanning items for purchase. Or, thecashier may invite the consumer to provide a user name, email address,or phone number at the end of the transaction, if the consumer wouldprefer to receive an electronic receipt.

The interface may be configured to serve multiple purposes. For example,the interface may be a magnetic scanner capable of reading magneticstripes of both payment mechanisms, such as credit cards, and consumeridentification mechanisms such as loyalty cards. The interface mayinclude prompts that indicate to the consumer when to provide theconsumer identifier, as opposed to when to provide other input. Or, thedifferences between the types of input received by the interface may besufficient enough that the entity processing the input can easilydistinguish between a consumer identifier and other input. The consumeridentifier may likewise serve multiple purposes. The terminal or retailserver may, for example, also use the consumer identifier to locateinformation such as digital coupons that are available to the consumer,a rewards account for the consumer, or a payment account for theconsumer. In an embodiment, an email address or store loyalty cardnumber may also be utilized to provide a consumer with benefits such asoffer redemption or membership discounts, or even to identify a suitablepayment mechanism.

The receipt of input via the provided interface of block 330 isoptional. In an embodiment, failure to receive input via the interfaceof block 330 before the expiration of a certain amount of time, orbefore certain terminal events such as the completion of the transactionor the pressing of a “Print Receipt” button, may be interpreted as theconsumer's implicit refusal of the option to receive an electronicreceipt for the transaction, per block 340.

Block 340 comprises receiving input indicating whether the consumerprefers to receive an electronic receipt for the transaction. In anembodiment, block 340 occurs in response to a prompt from the cashier orterminal, such as “Do you want a paper or electronic receipt?” or “May Iemail you your receipt?” The input may be received in a variety ofmanners, including the pressing of a key on a keypad or button on atouchpad. In an embodiment, the input of block 340 is the same as thatof block 330. That is, the consumer provides input indicating theconsumer identifier in response to being prompted to indicate whetherthe consumer would prefer an electronic receipt.

In an embodiment, the input of block 340 is received immediately priorto the provision of the interface for inputting the consumer identifier.For example, the cashier may ask the consumer if the consumer would likean electronic receipt. If the consumer responds affirmatively, thecashier may then prompt the consumer to swipe a consumer loyalty card orprovide a phone number.

In an embodiment, the input of block 340 may be implicit from theconsumer having provided a consumer identifier in block 330. In anembodiment, if the consumer identifier serves multiple purposes, theconsumer may be prompted to indicate whether the consumer prefers toreceive an electronic receipt even though the consumer has provided asuitable consumer identifier.

In an embodiment, the input of block 340 is received before thetransaction, in the form of a consumer preference for all transactionsbetween the consumer and retailer, or even between the consumer andmultiple retailers. The consumer may have previously expressed apreference to always receive electronic receipts, for example, during aregistration process, account management operation, or previoustransaction. Data indicating this preference may be stored inassociation with the consumer identifier or a corresponding consumeraccount. The transacting terminal or server may look to see if thepreference has been stored in association with the consumer identifieror the corresponding account prior to prompting the consumer for theinput of block 340. Or, the preference may be communicated along withthe consumer identifier when the consumer provides the consumeridentifier via a mobile device.

In an embodiment, the transacting terminal may send a request to aconsumer resolution component (e.g. provided by an offer distributor,cached locally, etc.) that includes information gathered from theconsumer. If the consumer resolution component can resolve theinformation to a consumer entity, the consumer resolution component mayreturn information about the consumer entity and/or digital receiptpreferences.

In an embodiment, the input of block 340 is optional. For example, aretailer may assume that a consumer prefers a paper receipt unless theconsumer proactively states otherwise. Or the retailer may assume thatthe consumer prefers an electronic receipt whenever possible.

If input indicating a consumer identifier has been received via theinterface of block 330 in association with the transaction, and if theconsumer indicated (or was assumed to have) a preference for anelectronic receipt per block 340, then at block 350 it is determinedwhether the consumer identifier is associated with a suitable electronicaddress to which an electronic receipt may be provided. Depending on theembodiment, the electronic address may take any of a variety of forms,including an email address, text messaging number, social messaging username, URL, website user account, and so on.

The determination may be accomplished using a variety of techniques. Forexample, a terminal may query a retail server using the consumeridentifier to determine whether consumer identifier is mapped in adatabase table to a suitable electronic address. As another example, aretail server may query a database server of store loyalty accounts todetermine whether the consumer identifier is associated with any of thestore loyalty accounts. If necessary, the retail server may then make anadditional query to the database server to see if an electronic addresshas been registered with the corresponding store loyalty account. Asanother example, a retail server may query a server hosted by an offerprovider or shopping incentive provider to determine whether theconsumer identifier is registered to a consumer account.

In an embodiment, the determination of whether a consumer identifier isassociated with a suitable electronic address is accomplishedimplicitly. For example, a retail server or offer server may storeinformation identifying a number of known consumer identities. Eachconsumer identity is assumed to be associated with a suitable electronicaddress either because of procedures followed when registering theconsumer identities, or because the server features logic for providingelectronic addresses such as personalized web pages for each consumeridentity. The determination of block 340 may thus be accomplished bydetermining whether the consumer identifier is associated with a knownconsumer identity.

Optionally, at block 360, if the consumer had indicated a preference toreceive an electronic receipt, but had not provided a consumeridentifier that was associated with a suitable electronic address, theconsumer may be prompted to provide a suitable electronic address forone-time use and/or for storage for future transactions.

If the consumer indicated (or was assumed to have) a preference for anelectronic receipt per block 340, and if a suitable electronic addresshas been located per block 350 or 360, flow proceeds to block 370. Block370 comprises causing provision of an electronic receipt, such asdepicted in FIG. 1, via an electronic address associated with theaccount. The electronic receipt optionally includes offer information,such as a link to a website comprising offers distributed by theretailer and/or the offer distributor, or data identifying one or morespecific offers for which the consumer is eligible. The identificationand provision of such offer information is described in subsequentsections.

Block 370 may be performed, for instance, by the terminal and/or theretail server directly providing the electronic receipt to an electronicaddress. The terminal and/or the retail server may or may not work incoordination with an offer server to identify relevant offer informationto include in the electronic receipt. In an embodiment, block 370comprises the terminal and/or the retail server sending transaction dataand either the electronic address or account identifying information forlocating the electronic address to a coordinating server. Thecoordinating server may be operated by any entity capable of providingelectronic receipts to the electronic address, including a serveroperated by an offer provider, payment provider, shopping incentiveprovider, or dedicated receipt provider. The coordinating server maywork with an offer server or retail server to identify relevant offerinformation, if necessary.

If the consumer indicated (or was assumed to have) a preference for aprinted receipt per block 340, or if a suitable electronic address isnot located per block 350 or 360, flow proceeds to block 380. Block 380comprises the terminal printing a receipt for the transaction. Thereceipt may optionally include offer information identified using anysuitable technique.

Flow 300 is one example of the variety of possible techniques forconducting a transaction in which an electronic receipt is provided.Other embodiments may include additional or fewer elements in varyingorders. For example, while flow 300 depicts an embodiment in which aconsumer is provided an electronic receipt instead of a printed receipt,other techniques may allow a consumer to select both a printed receiptand an electronic receipt. In yet other embodiments, a terminal neverprovides printed receipts. Rather, a consumer only has the option ofreceiving an electronic receipt.

In embodiments, the electronic receipt is provided directly to a mobiledevice operated by the consumer. In embodiments, the terminal may sendthe electronic receipt via a wireless link to an electronic address thatis either already known to belong to the consumer as a result of blocks310-330, or to a proximity-based communication interface presumed tobelong to the consumer. For example, the consumer may obtain the receiptby placing a mobile device near an NFC-capable terminal, and then eitherreceive the electronic receipt directly via NFC or indirectly viaback-end communications that were initiated using informationtransmitted via NFC. As another example, the consumer may use a mobileapplication on the mobile device to pay for the transaction, and thenreceive the electronic receipt via the mobile application uponcompletion of the transaction. The explicit identification of anelectronic address in block 350 may not be necessary in suchembodiments.

4.0. Example Functional Details

4.1. Electronically Providing Offer Information in Association with aReceipt

FIG. 4 illustrates a method flow 400 for electronically providing offerinformation in association with a receipt for a transaction conducted ata brick-or-mortar store, according to an embodiment. Flow 400 may beperformed by a variety of entities, depending on the embodiment,including the retailer, a retail server, a payment server, an offerserver, and/or any other suitable computing device.

Block 410 comprises receiving transaction information for a transactionbetween a retailer and a consumer, such as a transaction completed perblock 320 of FIG. 3. The transaction information includes accountidentifying information. The transaction information may also includevarious transaction details, such as a total price, a list of itemspurchased, information about offers or other discounts applied to thetransaction, and so forth. Depending on the embodiment, the transactioninformation may be received from any of the terminal, retail server,payment provider, or even the offer server.

The granularity of the transaction information may vary from retailer toretailer. For example, some retailers may provide only a total price,while others may provide detailed line-item descriptions of each itempurchased. In an embodiment, the transaction information may includepre-formatted receipt data or templates, to which offer information maybe added. In an embodiment, the transaction information contains no suchformatting. The account identifying information may be, for instance, aconsumer identifier received per block 330 of FIG. 3, or an accountnumber retrieved using the consumer identifier.

Block 420 comprises identifying an account associated with the accountidentifying information. Block 420 may involve querying one or moredatabases of account information held locally with the performing entityand/or at an offer server. Block 420 further comprises identifying anelectronic address associated with the account.

Block 430, which is optional, comprises selecting one or more offers forwhich the consumer is eligible. Block 430 may involve querying an offerdatabase, either directly or via an offer server, to retrieve offers. Inan embodiment, a variety of non-behavioral targeting mechanisms may beused to select the one or more offers, such as random algorithms,timestamps, campaign targets, and so forth. In an embodiment, thecriteria used to select offers may be associated with various aspects ofthe transaction information, such as keywords selected from itemdescriptions and item identifiers. In an embodiment, the one or moreoffers may be selected based upon one or more of: the one or more itemsinvolved in the transaction, transaction date and/or time, amount spent,consumer preferences, retailer preferences, consumer purchase history,retailer identity, store location, or consumer offer redemption history.In an embodiment, only a certain number of offers may be selected. Tothis end, block 430 may comprise ranking offers or requesting that anoffer server rank offers according to criteria such as described above.In an embodiment, the selected offers may be limited to those having acertain score in a ranking function. Any suitable techniques forselecting and ranking offers may be utilized.

Block 440 comprises generating an electronic receipt based on thetransaction information, such as depicted in FIG. 1. Block 440 maytherefore entail formatting both the transaction information and offerinformation as an electronic receipt. The formatting may be done inconformance with template data and/or logic for structuring anelectronic receipt based on the transaction information. In anembodiment, the electronic receipt may include logos, slogans, text, andlinks uploaded or otherwise provided by the retailer for use in all ofthe retailer's electronic receipts. In an embodiment, the offerinformation included in the generated electronic receipt may include oneor more links to a website or other resource at which detailedinformation about offers may be obtained, specific information aboutoffers selected per block 430, and/or links for obtaining coupons forspecific offers.

Block 450 comprises providing the electronic receipt, with the offerinformation, via an electronic address associated with the account.Block 450 may involve, for example, sending an email with the offerinformation to an email address that is stored in association with theaccount. Block 450 may alternatively involve receiving a client requestdirected a particular URL, and responding to the request with anelectronic receipt. The particular URL may be, without limitation, a URLthat was emailed or texted to the consumer, the URL of a page displayedby a coupon web application upon the consumer logging into the webapplication, a URL corresponding to the transaction in a transactionhistory for the consumer, or a URL corresponding to XML-based data thatis fed to a mobile application operated by the consumer. The electronicreceipt may have been generated prior to receiving the request from theclient. Alternatively, the transaction data may be stored in a database.In response to the consumer requesting the particular URL from theserver, the server dynamically generates the electronic receipt perblock 440, using the stored transaction data. Block 430 may also beperformed prior to or in response to the request for the particular URL.

In an embodiment, the offer information includes or links to otherinformation that includes an identification of one or more mechanisms bywhich the consumer may cause one or both of printing one or more couponsfor the one or more offers or saving one or more digital coupons for theone or more offers to the account associated with the consumeridentifier. The mechanisms may involve, for instance, one or more URLsthat request that an offer server generate a coupon for the selectedoffer. In an embodiment, the offer information includes printable copiesof the one or more offers. In an embodiment, one or more digital couponsare generated in block 430 and saved to the consumer's account. Block450, then, comprises informing the consumer of the existence of thedigital coupons in the consumer's account.

Flow 400 one example of the variety of possible techniques forelectronically providing offer information in association with a receiptfor a transaction. Other techniques may involve additional or fewerelements, in varying orders. For example, in an embodiment, theelectronic address is received directly from the terminal or retailserver. The account identifying information and the account itself maytherefore be unnecessary.

4.2. Example Offer Activation Interface Components

In an embodiment, an offer distributor provides a portal application orwebsite comprising a receipt component, offer component, and shoppinglist component. A consumer may access the portal directly through aserver hosted by the offer distributor, such as a website hosted on theoffer server and/or receipt server. The consumer may also or insteadaccess the portal via a retailer, payment provider, or other third-partyentity website, in which the portal has been embedded as a microsite.The microsite may be tailor to the website in which it has been embeddedthrough the use of third party entity-provided templates that areprocessed by the distributor and/or entity-based post-processing of theportal. In other embodiments, an entity may offer equivalent and/orother interfaces by retrieving data via a suitable API from atransaction aggregation and/or offer distribution system, and processingthat data to form its own portal. In an embodiment, the portal isformatted differently for different contexts, such as viewing from atraditional web browser as opposed to viewing from a mobile device.

With the receipt component, various interfaces are provided fordisplaying lists of available digital receipts, displaying detailedindividual digital receipt, displaying sales histories and aggregatedtransaction data, and/or displaying product details. With the offercomponent, various interfaces are provided for searching offers,displaying lists of available offers, displaying information aboutoffers, activating offers, and/or displaying lists of offers that willexpire shortly. With the shopping list component, various interfaces areprovided for adding items to a shopping list, displaying shoppinglist(s), and managing a shopping list. The components are notnecessarily distinct from each other. For example, interfaces for theoffer component may be embedded within or displayed adjacent tointerfaces for the receipt component or the shopping list component.

Simple Offer Activation Interface

FIG. 2 depicts an example graphical user interface (“GUI”) 200 withwhich a consumer may view and select offers. GUI 200 may be displayed,for example, by a dedicated coupon client or a web browser executinginstructions from an offer server. The consumer may arrive at GUI 200,for example, by selecting links 151-154 in email 100, or by launching ageneral purpose offer interface and then navigating to a section atwhich offers selected for the consumer are presented. For example,selecting links 151-154 may launch a web browser to a Uniform ResourceLocator (“URL”) at a retail server or offer server. The consumer may ormay not be required to first log in to his or her account. In anembodiment, the URL may be a general purpose URL, and the offersdisplayed in GUI 200 may have been selected without regard to anytransaction. In an embodiment, the URL, or accompanying data, mayidentify to the server the specific offers displayed in GUI 200. In anembodiment, the URL, or accompanying data, may instruct the server tolocate offers that were identified for the consumer in response torecent transactions or a specific transaction.

As another example, selecting links 151-154 may launch a dedicatedcoupon client that interfaces with an offer server. Selecting links151-154 may launch the dedicated coupon client with input such as anaccount identifier, offer identifiers, and/or transaction identifiers.The dedicated coupon client may then use the inputted information torequest that the offer server provide data such as depicted in GUI 200.The dedicated client may then generate GUI 200.

As another example, the consumer may launch a mobile coupon client on asmartphone, without having selected a link in an electronic receipt. Theconsumer may then navigate to a screen entitled “Special Offers,” whichdisplays offers downloaded by the client from an electronic addressbased on credentials entered by the consumer. In an embodiment, themobile client may have notified the consumer that new offers areavailable prior to the consumer having launched the coupon client.

In an embodiment, GUI 200 displays information about offers 211-214. Thedisplayed information includes controls 221-222 for printing offers211-212 respectively. The displayed information further includescontrols 231-232 for saving offers 211-212, respectively, to aconsumer's account. There are no controls for selecting offer 213, butrather an indicator 243 that the offer 213 has already been saved to theconsumer's account. Likewise, there are no controls for selecting offer214, but rather an indicator 244 that the offer 214 has already reacheda distribution limit.

Selection of the controls 221-222 or 231-232 may result in the issuanceof a request to an offer server to generate a coupon for thecorresponding offer. Selection of one of print controls 221-222 may morespecifically result in the client downloading a printable coupon for thecorresponding offer and outputting the downloaded coupon to a printer.Selection of one of controls 231-232 may more specifically result in theclient sending a user identifier or session identifier to an offerserver, along with a request to store a digital coupon for thecorresponding offer in an account associated with the user identifier orsession identifier.

GUI 200 may optionally include fields that explain why some or all ofthe offers are being presented to the consumer. For example, a note nextto one of the offers may explain to the consumer that the offer wasselected for the consumer because of an item purchased in a specifictransaction. The field may even include a link to another interface,such as another web page, from which the consumer may review details forthe specific transaction, such as receipt data 130. In an embodiment,the field may further include a control by which the consumer mayexpress a preference to not receive future offers related to thepurchased items.

GUI 200 is one example of an interface that may be displayed forselecting offers. Other interfaces may include additional or lessinformation in varying arrangements. For example, an interface may onlyinclude offers related to a single link 151-154 of email 100. As anotherexample, an interface may only allow a consumer to print coupons, oronly allow the consumer to save digital coupons.

4.3. Electronic Receipts

Various embodiments involve providing consumers at brick-and-mortarstores with electronic receipts instead of, or in addition to, printedreceipts. The electronic receipts may be provided to the consumers in avariety of ways. For example, the electronic receipt may be included inor attached to an email. Or, the electronic receipt may be provided in aweb page on a website hosted by the retailer or a third-party, such asan account history page or “digital locker” of receipt data. In anembodiment, the consumer may access the web page at any time after thetransaction by logging into the website using credentials thatauthenticate the consumer. In an embodiment, the consumer receives alink to the web page via email, a text message, or any other electronicaddress, including private messaging addresses on social networks. Theconsumer provides a suitable address for the receipt during thetransaction. Or, the consumer provides an identifier, such a storeloyalty card or RFID tag, to the retailer so that a suitable electronicaddress to which to provide the electronic receipt may be located.

As yet another example, the consumer may obtain an electronic receiptusing a dedicated transaction management application. The dedicatedtransaction management application, which may also double as a paymentapplication and/or coupon application, may communicate with a server toobtain receipt data that has been uploaded by retailers in associationwith an account belonging to the consumer. The application may thenorganize that receipt data for presentation to the consumer. In anembodiment, the transaction management application may monitor theaccount for new receipts periodically, or receive push-notifications ofreceipts from the server. The receipt management application may thennotify the consumer when a new receipt is available.

Various embodiments may also or instead involve providing consumers withoffer information via an electronic address in response to thecompletion of a transaction. The offer information may include digitalcoupons themselves, and/or links to locations at which the consumer mayprint or otherwise obtain coupons. In an embodiment, offer informationis embedded in an electronic receipt.

In an embodiment, an electronic/digital receipt interface includes acontrol for printing a return receipt. In response to a consumerclicking on the control, a return receipt, including a transactionidentifier barcode, is printed.

In an embodiment, a retailer or payment provider creates electronicreceipts by requesting receipt data structures from a receipt serversuch as receipt server 1370 and then formatting the receipt datastructures in accordance with retailer-customized templates. In anembodiment, the retailer instead provides suitable template(s) to theretail server 1370. Different templates may be used for differentcontexts, such as email as opposed to web page as opposed to SMS.

In an embodiment, an example template for a digital receipt divides areceipt into five sections, including: a header information sectioncomprising store information and branding, general transactioninformation, and a receipt barcode; an item details section that liststhe products purchased, including information such as UPCs, SKUs,descriptions, prices, price modifiers, quantities, and/or other suitableline item details; a totals area, including sub totals, tax totals,balance due, and total savings; a tender area comprising informationabout the form(s) of payment, and amount(s) of payment, and a trailerarea allowing for terms of sale, branding, and loyalty greeting(s). Inan embodiment, APIs allow a retailer or other entity to retrieve datastructures corresponding to each of the above.

Example Electronic Receipts

FIG. 1 depicts a display of an email 100 comprising an electronicreceipt 130 with offer information 151-154 that has been provided to anelectronic address 111 of a consumer. Email 100 may be displayed in thedepicted manner by, for example, a client-based or web-based emailapplication that interprets various fields, metadata, and or markuplanguage included in email 100. Email 100 comprises a variety of headermetadata 110, some or all of which may be displayed at the top of theemail. Header metadata 110 may include, for example, an electronicaddress 111 of a consumer. Email 100 may further include a message 120.

Electronic receipt 130 of email 100 is depicted in FIG. 1 as one or morehyper-text markup language (“HTML”) tables, but in other embodiments theelectronic receipt may take any suitable form. Electronic receipt 130comprises transaction details 135, such as a transaction number, a timeor date of the transaction, a store location at which the transactiontook place, an identifier for a terminal at which the transaction tookplace, the name of a sales representative that assisted in conductingthe transaction, the name of the consumer, and so forth. Electronicreceipt 130 further comprises an item list 140 of items 141-145 thatwere purchased in the transaction, a transaction total 180, and paymentdata 190.

Item list 140 may include, in association with items 141-145,basket-level details such as the quantities of each item purchased, aprice for each item, offer redemption data 170 for offers applied to thetransaction, tax data, SKU numbers, and so forth. Payment data 190 maycontain a list of each payment mechanism applied to the transaction,along with any balance remaining

Offer information 151-152 is intermingled within item list 140.Specifically, offer link 151 is displayed after item 142 and offer link152 is displayed after item 145. As depicted, the offer(s) associatedwith links 151 and 152 are selected at random. However, in otherembodiments the offers associated with offer information 151-152 mayhave been selected for inclusion in email 100 based on items 142 and145, respectively. Offer information 153 is displayed in associationwith payment information 190, and the offer associated therewith mayhave been selected for inclusion in all receipts provided via email.Alternatively, in an embodiment, offer information 153 may have beenselected for inclusion in email 100 because of the payment method chosenby the consumer. Offer information 154 is displayed at the end of theemail, and the corresponding offer may have been selected for any of anumber of reasons as discussed herein. In other embodiments, offerinformation 151-154 may be entirely intermingled with the electronicreceipt 130, or displayed entirely separate from the electronic receipt130.

As depicted, offer information 151-154 includes a link to thelocation(s) of one or more offers, along with short description(s) ofthe offer(s) available on those pages, designed to encourage theconsumer to click on the links. Each offer link 151-154 may link to asame or different location. For example, each link may take the consumerto a different offer page on the website of an offer provider. Eachoffer page may comprise one or more offers relevant to the selectedlink. Or each link may take the consumer to a same page containing allof the indicated offers.

In other embodiments, offer information 151-154 may include additionalinformation about the available offers, such as a list of eligibleproducts and store locations, expiration dates, discount amounts, andother terms. In an embodiment, offer information 151-154 may includecontrols associated with each indicated offer, such as a “Print now”button or “Save to Card” button, by which the consumer may immediatelydownload, print, and/or save a coupon for the indicated offer. In anembodiment, offer information 151-154 may be part of a form comprising achecklist or pull-down menu of offers and controls for printing, saving,or otherwise accessing coupons for any offer that the consumer selectsvia the form. In an embodiment, offer information 151-154 may indicateto the consumer offers that have automatically been added to theconsumers' account in response to the transaction.

Email 100 may optionally include relevant advertisement data, such asadvertisement 180, that is not an offer. For example, as depicted,advertisement 180 is a special promotion that provides the consumer withaccess to a multimedia item related to the purchased item 143.

Email 100 is one example of a technique for providing a consumer with anelectronic receipt. In other embodiments, the electronic receipt may beembedded in differently formatted emails, other types of messages, webpages, and/or documents. Furthermore, electronic receipt 130 may includemore or less transaction data, in varying arrangements. In anembodiment, email 100 comprises only electronic receipt 130 or onlyoffer information 151-154. In an embodiment, the information in email100 may be divided amongst multiple electronic addresses. For example,the offer information 151-154 may be in a different email or on a webpage. In an embodiment, the offer information 151-154 is substituted inemail 100 with single link having a label such as “Access Your Coupons.”

FIG. 35 illustrates an example webpage 3500 comprising an electronicreceipt 3550 with embedded offer information, according to anembodiment. Web page 3500 comprises a merchant logo 3501, receipt number3502, current savings area 3503, transaction information area 3504, mainnavigation menu 3505, option popup menu 3506, transaction summary area3507, percentage savings area 3508, greeting area 3509, help area 3510,pre-activated coupon area 3511, recommended coupon area 3512, andbest-selling item area 3513.

Merchant logo 3501 allows a retailer to display their logo from abranding perspective. The logo may be text or image. Current savingsarea 3503 displays a consumer's total number of activated offers(clipped coupons). This section provides information on the number ofcoupons added and the coupon savings in dollar amount. Coupons added andcoupon savings will display 0 and $0.00 when there are no activatedoffers. Transaction information area 3504 captures information from thetransaction log pertaining to the retailer, such as: date and time ofpurchase, store address, store phone number.

Main navigation menu 3505 displays, after clicking the links in a publicreceipt, a prompt to sign in. After “signing in” the consumer will beable to navigate within the portal. This section has multiple tabs thatenable to consumer to be able to view various interface elements such asa Coupons Tab that allows the consumer to view a coupon gallery whereconsumer can activate coupons, a Lists Tab that shows pre-activated andactivated coupon lists, and a Receipts Tab that will allow the user toview all the receipts. The consumer is able to toggle between thesevarious tab views by clicking on the tabs of the module.

Option popup menu 3506 gives the consumer options such as option toprint this receipt, email it, delete it, or add all the receipt's itemsto a shopping list. A mockup overlay 3556 for popup menu 3506 appears tothe right of web page 3500. Hovering the mouse on the icon for popupmenu 3506 opens up the overlay 3556, with the controls for print, email,delete, or add items to shopping list options.

Transaction summary area 3507 displays information such as sales tax,transaction total, and savings amount. Percentage savings area 3508indicates the amount saved in the transaction. Transaction details area3575 shows the line item, basket level details for the transaction. Eachitem may be broken down into an item category. An indication of the itemamount and any discount applied are given. Clicking on the item may, forexample, bring up an item detail sidebar or popup overlay withnutritional data, ingredients, specifications, product images, itemdescriptions, offers related to the item, and/or other information. Or,such information may be displayed in a separate item detail page. Or, asanother example, clicking on an item in area 3575 may bring up a pop-upmenu 3576 with selectable controls to perform actions such as printingor emailing information about the selected item, adding the selecteditem to a shopping list if the item is not already in a shopping list,and so forth.

Welcome area 3509 allows a consumer to, by clicking on the down arrow,can edit account preferences and/or sign out. Clicking on the down arrowopens the overlay 3559. Help area 3510 comprises a link to a FrequentlyAsked Question page and other support features.

Pre-activated coupons area 3511 displays the consumer's latestpre-activated offer. The consumer has the option to expand the containerby clicking on the “Show more” link to view any more activated coupons.This section provides the information on the number of coupons added andthe coupon savings in dollar amount. Recommended coupons area 3512contains a list of additional coupons for user to activate. A consumermay activate a coupon by clicking on the add control associated witheach coupon. Best-selling items area 3513 is a list of items that areselling well, and may be of interest to the consumer.

Example Receipt List Interface

FIG. 36 illustrates a webpage 3600 comprising an interactive list 3650of a consumer's receipts, according to an embodiment. A transactionaggregation area 3601 displays the total number of receipts, totalsavings, and total spending for the consumer, as aggregated from alltransactions mapped to the consumer. List 3650 comprises a number ofdifferent receipt summaries 3655, which may display differentinformation depending on the view. For example, as depicted, the receiptsummaries 3655 depict a date, day of week, transaction total, paymenttype, and total savings. Clicking on a receipt summary 3655 may take theconsumer to a receipt web page such as web page 3500 above. Or, clickingon or hovering over a receipt summary 3655 may cause the summary to betransformed into an expanded receipt summary. Or, clicking on orhovering over a receipt summary may cause the expanded receipt summaryto display in a popup overlay. Examples of expanded receipt summariesare depicted in overlay 3665, which lists a few selected items 3666 ofthe total number of items involved in the transaction, along with acouple of related offers 3667. A separate, full receipt detail page maybe launched using control 3668.

Sort/filtering controls 3602 allow a user to enable various views of thelisted receipts, including views by various key features such asPurchase History, Payment Type, Last 7 days, and/or Last 30 days.Navigation controls 3603 permit navigation of list 3650. Receipt actioncontrol 3605 gives the customer a pop-up menu interface 3675 havingcontrols with the options to print, email or add receipt items toshopping list(s).

Webpage 3600 further includes pre-activated coupon area 3611,recommended coupon area 3612, and best-selling item area 3613, similarto those found in web page 3500.

4.4. Example User Interaction Data Flow

As an example, a consumer's experience with an embodiment of certainsystems and techniques described herein is as follows. The consumercompletes shopping and identifies themselves using a retailer's pin-padby entering a phone number or email identifier and/or swiping a loyaltycard or a credit card. The consumer makes a payment for items in his orher basket at the point-of-sale. The consumer specifies a choice forwhether to receive a digital receipt, and his or her preferences fordelivery of that receipt. Or, the choice is identified based onpreviously collected consumer preferences. The consumer receives adigital receipt either through email or text. The consumer views offerspresented in the receipt and may activate offers for future use.

The flow of data between various system components that enable thisconsumer experience is, according to an embodiment, as follows. Thepin-pad will interact with a local server, deployed by the offerdistributor within the retailer's data center, to resolve the consumer'sidentity and, if available, retrieve their digital receipt preferences.The pin-pad will interact with the local server located within retailerenvironment to identify a consumer and retrieve their digital receiptpreferences. The pin-pad will send the consumer's information, liketheir loyalty identifier, phone number, email identifier, or a tokenbased on the Payment Card Number (PAN) to the local server. The localserver will try to identify the consumer and send their digitalpreference back to the pin pad. The local server is synchronized withthe offer distributor's central consumer database periodically.

The point-of-sale utilizes a trickle upload server to send transactionlogs, possibly in near-time, from the store to a central sales hub in aretail data center. The transaction log(Tlog) is then sent via a flatfile, possibly on a real time basis, to a transaction aggregationgateway for presentation of digital receipts. The data from sales hub isdistributed to various other systems within the retailer environment.Through a fork the same transaction log may be sent to the gateway forpresentation of digital receipts. A flat file may be sent for each Tlogtransaction that includes transaction information. Three example formatsfor sales transactions from retailers are IBM Tlog, POS Log—ARTSstandard, and a transaction-aggregation system canonical format that isnon-binary.

Real time Tlogs from retailers enter through the gateway. The gatewaysupports multiple interface protocols, such as web services and messagequeues. The Tlog is processed in the gateway using the following threeprocesses: 1) Security: the Tlog is received as a message and validatedagainst defined message and channel level security policy; 2)Transformation: the Tlog message is transformed from retailer specificformat to the canonical format using accelerators for fasttransformation; 3) Queues: the transformed Tlog messages are queued forfurther processing by the event processing engine.

The Tlog is then processed by an event processing engine. The eventprocessing engine contains three components: producers, processingengine, and consumers. Event producers manage real time sale transactionmessages, offer activations, and/or the various other events describedherein. Event processors route the events based on attributes based onrules such as, if a consumer chooses SMS as a choice, then the event isrouted to an SMS adaptor. Example event consumers include SMS adapter—tosend SMS using notification services; Email adapter—to send Email usingnotification services; Store in database—to store sale transaction indatabase; Preloading offers—to preload recommended offers to a customerin the event the customer requests digital receipt.

The consumer data from the Tlog data is loaded into consumer tables inthe operational data store (ODS) after validating it using the businesslogic. The business logic is based on the business rules established bythe offer distributor. The following information from the Tlog will bestored in the consumer database in ODS: Loyalty Id, PAN number, EmailId, and/or Mobile phone number.

Data from the ODS is moved to a data warehouse for analytics purposesusing ETL tools in a batch mode. Consumer data such as consumer names,address, demographics, email ids, PAN, Phone numbers, social media,device, loyalty, and other information, is loaded in to consumer tablesin warehouse. These ETL processes are also used to load bulk data frompartners in to the ODS. The ETL processes run in batch mode to move datafrom ODS to Data warehouse.

Any offers activated by the consumer are sent to each retailer's offermanagement system in the central sales hub, so as to allow them to beredeemed. The offer information will be sent real time to the retailer.Optionally, the offers can also be stored in offer distributor's localserver and made available through it. The central sales hub sends thisinformation, along with item information and pricing information to thepoint-of-sales.

Information about offers that are actually redeemed by the consumers issent back to the offer distribution server on a near time basis. Thisinformation is stored in the ODS and fed back to the data warehouse forfurther analytics and reporting purposes.

The offer server receives certain consumer master data from retailersand other partners on an ongoing basis, and from third party companieson an ad hoc basis. This data is loaded into the ODS along with theoffer distributor's own consumer information, and subsequently moved todata warehouse to create digital profiles for the consumers.

The retailer's local server synchronizes with the offer distributor'scentral server on an ongoing basis. Reporting programs pull consumerinformation from the data warehouse to generate reports.

4.5. Example Offer Data Flow

An example offer data flow is as follows. Manufacturers, advertisers,retailers, and others work with the offer distributor to develop contentto be marketed within the offer distributor's network. Offers arecreated in the distributor's offer management system. Certain offershave a print-at-home designation and are loaded into a separatedistribution system for printable coupons. Other offers are digitaloffers, which are processed by offer business logic and loaded intooffer tables in the ODS. These offers are pushed from ODS to the datawarehouse on a regular basis.

In one embodiment, on a periodic basis, such as daily or every 15minutes, the recommendation engine may read TLog data, redemption data,and offer data from the ODS. The engine runs the recommendationalgorithm, processes business rules, performs post-processing, and ranksoffers in the ODS. Meanwhile, a targeting engine retrieves targetinginformation and offers from the data warehouse. The targeting enginematches the offers to targeted consumers in the data warehouse. Anymatched manually targeted offers are then send from the data warehouseto the ODS. On a periodic basis, all of the offers (including therecommended and manually targeted offers) for a consumer are pooled inthe ODS.

A consumer requests a digital receipt at the point-of-sale using, forexample, a pin-pad or other interface. The retailer sends the consumer'sTlog data on a real time basis to the gateway. The Tlog data isprocessed by the gateway, event processing engine, and then by businesslogic, and is loaded into a sales tables in the ODS, as described inother sections.

A digital receipt service, or other requestor of offer recommendations,calls a recommendation engine for the most appropriate offers based on aconsumers' Tlog (basket) data and/or other factors such as a consumername, address, demographics, email identifier, PAN, phone number, socialmedia data, device identifier, loyalty data, and so forth. On therequest, the recommendation engine will read the pooled offers from theODS, optimize the recommendations based on the basket data, and createan new offer list that's most relevant to the consumer in the ODS. Invarious embodiments, a recommendation engine may use contextualtransaction data and/or historical transaction records to identifyand/or rank recommended offers.

The final offers list is sent to the digital receipt, or to an offerdistributor consumer interface via business services, based on the calland context. In the case of the digital receipt service, the digitalreceipt and the offer are sent to the consumer via the consumer'spreferred delivery method. The finally recommended offers may be loggedin an offer status table that indicates impressions.

The consumer activates offers, and the list of activated offers is sentto ODS. Activated offers are sent from ODS to an offer database in thedata warehouse. The inventory for these activated offers is reduced inthe offer management system. A consumer subsequently redeems offers atthe point-of-sale. Partners, such as retailers or clearinghouses, sendoffer redemption information to the ODS via bulk data exchange. Aconsumer offer table is updated with this information.

4.6. Example Notifications and Other Messages

In an embodiment, in addition or instead of providing consumers withindividual receipts, a receipt server may provide consumers withperiodic aggregated reports of their transaction activities. Forexample, a receipt server may email a monthly report of a consumer'saggregated purchases at a certain store. The report may emphasize howmuch money a consumer saved by accepting various offers, and/or show theconsumers how much money they could have saved had they used certainoffers. Consumers may then activate or reactivate these offers, orsimilar offers.

In an embodiment, a portal for viewing offers and/or receipts features amessage preference area, by which a consumer may elect to receivecertain types of email, SMS, and/or web-based notifications, includingnotifications of new receipts and account changes, as well periodicnotifications, such as weekly notifications of offers not yet redeemed,offers expiring within a consumer-specified upcoming time frame,shopping list items, and/or upcoming sales events.

In an embodiment, an offer distribution system sends regular messagesand notifications for coupons that are expiring, new deals, and soforth. In an embodiment, an offer distribution system provides consumerfrequency data to retailers, thus allowing retailers to send anautomated email to inactive consumers. For example, after 45 days, theretailer may send an inactive consumer the message: “It's been a whilesince we've seen you,” along with offer(s) recommended for the consumer.

4.7. Example Recommendation Engines

FIG. 32 illustrates a process flow 3200 for an example recommendationengine, according to an embodiment. Transaction logs 3255 are mined foroffer redemption data 3288 and basket data 3271. Recommendations aregenerated from transactions 3255 directly by identifying best-sellingproducts 3272 in basket data 3271 and frequently redeemed offers 3291 inoffer redemption data 3288. The frequently redeemed offers 3291 arerecommended as personalized recommendations 3296. Offers 3274 areidentified for the best-selling products 3272, and then used aspersonalized recommendations 3276.

Recommendations are generated from transactions 3255 indirectly byidentifying associative pairs 3292 of offers frequently redeemedtogether in offer redemption data 3288, and associative pairs 3273 ofitems frequently purchased together. The associative pairs 3292 are usedto identify related recommendations 3297. Offers 3275 are identified forthe items in associative pairs 3273, and then used as relatedrecommendations 3277.

FIG. 33 illustrates another example recommendation engine based on sixdifferent scoring functions 3374-3379, each of which is a specific to acertain category of signals, according to an embodiment. Thesecategories include shopping lists 3354, web clickstream 3355, offersclickstream 3356, coupons activation log 3357, offers redemption log3358, and transaction logs 3359.

Each data source 3354-3359 will provide a separate recommendation set3352 a-3352 f, having its own distinct scoring. The recommendations sets3352 a-3352 f are merged by assigning a different weight 3381 a-3381 fto every recommendation set 3352 a-3352 f. Initial weights can all beset to the same value, or learned by experience. In an embodiment,weights 3381 a-3381 f grow from left to right, indicating that the datasources 3354-3359 increase in relevance in that same order. However,other weightings are also possible. Alternatively, only some or evennone of the recommendation sets 3352 a-3352 f are merged. Rather,different recommendation sets 3352 a-3352 f are used for differentsituations.

In an embodiment, weights 3381 a-3381 f are continuously updated toreflect the dynamic nature of data sources, the information richness ofeach source, and/or to compensate for malicious data sources. In anembodiment, tentative weight values are as follows: Weigth 3381 a:20-40%, Weight 3381 b: 40-50%, Weight 3381 c: 40-50%, Weight 3381 d:60-80%, Weight 3381 e: 90-100%, Weight 3381 f: 90-100%.

Distributed Algorithm Implementation

In an embodiment, mapper and reducer programs enable generatingrecommendations in parallel. These programs rely on the computationalpower on clusters of machines as well as network bandwidth on theconnections linking the clusters together.

In a basic parallel association analysis, the input type is the same asthe output item types, and the algorithm effectively reduces to avariation of a self-join operation. Individual transactional orders areseparately processed in association-pair mapper tasks that outputprimary items as keys, and secondary/recommended items and their weightsas values. The Map-Reduce framework will shuffle and re-arrange theoutputs by their keys (primary items) for feeding into reducer tasks.The reducers then calculate and sort the final pairwise associations inthe form of an item-item association or similarity matrix. Each row ofthe item-item similarity matrix is then sorted to rank therecommendations by a pre-specified metric.

4.8. Example Signals/Kpis

In an embodiment, in addition to the other categories of data sourcesdescribed herein, signals for scoring functions may be derived fromoffer validity data, inventory data, revenue data, and/or transactiondata.

In an embodiment, a scoring function that has been developed takes intoaccount several signals including how frequently a pair is purchased, byhow many different consumers, when they are purchased, and where theyare purchased. The signals include: number of unique purchasers of pair{i_(k),i_(m)}, total appearances of pair {i_(k),i_(m)}, time ofpurchase, relative price of items purchased together, and/or location ofpurchase.

In an embodiment, signals derived from transaction data may includemetrics based on: departments in which consumers cross-shop, privatelabel products that certain consumers prefer, frequency with which aconsumer responds to offers, percentage of a consumer's baskets thatcontain an selected product, which items are actually in their marketbasket, projections of whether a particular consumer will actuallyrespond to a particular offer, whether the consumer tends to only buyproducts on sale, and whether the consumer tends to buy advertised items(as may be indicated by correlations between purchases and separateadvertising data).

In an embodiment, these and other metrics may be utilized for thepurpose of dynamic offer valuation and/or price discrimination. Forexample, based on the above metrics, an offer distribution system may beable to estimate exactly how big of a discount amount is needed toentice a consumer to accept an offer. This dynamically computed amountis shown to the consumer when recommending an offer, and may even changeif the consumer fails to activate or use the offer within a certaintime. The dynamically computed amount is then stored in the offeractivations records, so that it may be applied correctly.

Example Kpis

Example metrics to be used in generating recommendations include,without limitation, those in the following table. These KPIs may be usedin a number of functions, including, without limitation: assessing theperformance of coupons, and identify the best-selling ones or thecoupons with the estimate the benefits for the distributor and otherstakeholders, identify the best customers, estimate the revenue for thedistributor and other stakeholders (manufacturers, retailers) that eachoffer generates, post filter the generated recommendations by applyingspecific thresholds, either hard or soft, that one, several or afunction of these KPIs need to satisfy, assess the performance ofrecommendations by estimating the lift that the provided recommendationsgenerate in each of the monitoring KPIs, training the recommendationengine, calculating a universal score for an offer, scoring potentialoffers to propose that a provider create, estimating a potential offer'seffectiveness, and so forth.

KPI Description Number of coupons per The number of coupons per basketfor the customers of the basket distributor is a measure of thepenetration of coupons in the basket of a customer. For example, on anaverage, a coupon customer uses X coupons per basket during a certainperiod. For every customer calculate AVG number of coupons redeemed perBasket over a time period, then calculate the average of the abovecalculated figure across all customers. Number of coupons per The numberof coupons that every customer uses over a specific customer period isan indication of his utilization of coupons.com offers. For example, onan average, a coupon customer uses X coupons during a certain period.For every customer calculate the total number of coupons redeemed over atime period, then calculate the average of the above calculated figureacross all customers Number of Coupons per By looking at this ratio thedistributor can have an idea of the items purchased within contributionof coupons in the revenue from a specific customer. each basket Forexample, on an average, a coupon customer's shopping basket has 60%items purchased with coupons during a certain period. For every customercalculate the average of (number of coupons/ number of items) per basketover a time period, then calculate the average of the above calculatedfigure across all customers Number of Coupons Per Identify thoseretailers that generate the higher revenues for the retailerdistributor. For example, during a certain period: X coupons wereredeemed from Retailer A; Y coupons were redeemed from Retailer B Forevery customer calculate the total number of coupons redeemed perretailer over a time period, then calculate the SUM of the abovecalculated figure across all customers per retailer Number ofImpressions Quantifies the number of times each coupons has been shown.per Coupon This can be broken down to customer level. For example,during a certain period, AVG Figure: Coupon A was displayed X number oftimes per customer; Total Figure: Coupon A was displayed Y number oftimes in total to all customers For every coupon, calculate the totalnumber of times it is displayed to customers during a certain timeperiod, then divide the above calculated figure with number of customersthe coupon is displayed to Number of Customer The number of Customeractivations per coupon is a metric of the Activations per couponpopularity of each coupon. For example, Coupon A was activated X numberof times during a certain time period Number of Customer The number ofCustomer activations per coupon is a metric of the Activations percoupon by popularity of each coupon via Save to Card. For example,Coupon context (e.g. print, digital) A was activated X number of timesduring a certain time period in a certain context. Number of Auto- Thenumber of auto-activations per coupon during a certain time Activationsper coupon period is a metric of the popularity of each coupon. Numberof Total The number of total activations (including auto-activated andActivations per coupon customer activated) per coupon during a certaintime period is a (auto-activated and metric of the popularity of eachcoupon. customer-activated coupons) Number of redemptions The number ofredemptions per coupon during a certain time per coupon for Customer-period is an indication of purchases a coupon might have activatedcoupons triggered. Number of redemptions The number of redemptions percoupon during a certain time per coupon for Auto- period is anindication of purchases a coupon might have Activated triggered. Numberof redemptions The number of redemptions per coupon during a certaintime per coupon for Total period is an indication of purchases a couponmight have Activated triggered. Number of redemptions The number ofredemptions per coupon during a certain time per coupon for Customerperiod in a certain context is an indication of purchases a couponActivations by context might have triggered. (e.g. print/digital) Offerdistributor Revenue Identify the most profitable coupons. The averagerevenue per per Coupon coupon is an indication of the averageperformance of all coupons. For every coupon, calculate revenue over aperiod through activation at coupon.com and affiliated websites, thenaverage the above figure across all coupons will give average revenueper coupon Retailers Revenue per Identify the coupons that generate thehigher revenue for Coupon Retailers/manufacturers. Sum of sales forevery type of coupon that was used. Offer distributor Revenue Aids indetermining the effectiveness of each coupon for the Per Impressiondistributor, since it compares the revenues that each coupon generatesfor the distributor to the number of times this has been presented tocustomers. For every coupon, calculate revenue over a period throughactivation divided by number of times it is presented to customersduring the same period Retailer Revenue Per Aids in determining theeffectiveness of each coupon for retailers Impression and manufacturer.Sum of sales for every type of coupon divided by the impressions of thiscoupon Offer distributor Revenue Determines the revenue generated perCustomer activations for Per Customer Activation each coupon.Distributor Revenue Per Determines the revenue generated perauto-activations for each Auto-Activation coupon. Distributor RevenuePer Determines the revenue generated per total activations (includingtotal Activation (auto- auto-activated and customer activated) for eachcoupon. activated and customer activated coupons) Distributor RevenuePer Determines the revenue generated per Customer activations byCustomer Activation by Save to Card for each coupon. context RetailerRevenue Per Determines the retailers' revenue per activation for eachcoupon. Customer Activation Sum of sales of items for which a specificcoupon was used divided by the number of activations of this couponRetailer Revenue Per Auto Determines the retailers' revenue perauto-activation for each Activation coupon. Sum of sales of items forwhich a specific coupon was used divided by the number of activations ofthis coupon Retailer Revenue Per total Determines the retailers' revenueper total activations (including Activation (auto- auto-activated andcustomer activated) for each coupon. activated and customer Sum of salesof items for which a specific coupon was used activated coupons) dividedby the number of activations of this coupon Retailer Revenue PerDetermines the retailers'revenue per activation by Save to Card CustomerActivation by for each coupon. context Sum of sales of items for which aspecific coupon was used divided by the number of save to cardactivations of this coupon Revenue per Redemption For every coupon,calculate revenue over a period through for Customer Activatedactivation divided by number of times it is redeemed during the couponssame period Distributor Revenue per For every coupon, calculate revenueover a period through Redemption for Auto- activation divided by numberof times it is redeemed during the Activated same period DistributorRevenue per For every coupon, calculate revenue over a period throughRedemption for Total activation divided by number of times it isredeemed during the Activated same period Distributor Revenue per Forevery coupon, calculate revenue over a period through Redemption forCustomer activation divided by number of times it is redeemed during theActivated by context same period for coupons activated in the contextRetailer Revenue per Sum of sales of items for which a specific couponwas used Redemption for Customer divided by the number of redemptions ofthis coupon Activated coupons Retailer Revenue per Sum of sales of itemsfor which a specific coupon was used Redemption for Auto- divided by thenumber of redemptions of this coupon Activated Retailer Revenue per Sumof sales of items for which a specific coupon was used Redemption forTotal divided by the number of redemptions of this coupon ActivatedRetailer Revenue per Sum of sales of items for which a specific couponwas used Redemption for Customer divided by the number of redemptions ofthis coupon for activated Activated by Save to Card by print couponscoupons Retailer Revenue per Sum of sales of items for which a specificcoupon was used Redemption for Customer divided by the number ofredemptions of this coupon for save to Activated by Print card activatedcoupons coupons Clip rate per Impression This is the number of activatedcoupons per impression. (i.e. strip out price Number of Impressions percoupon/Number of Activations per weighting, effectively coupon givinglower priced items equal weight) Redemption rate of Number ofredeemed/number of activated coupons coupons after clipping Customer:return trips to Number of visits of every customer to the websitewebsite (Distributor/Retail). This can also be expressed as frequency,that is the number of visits per week For every customer, calculate thenumber of times he/she visited the Coupon.com website during a certainperiod Customer: return trips to Number of visits of every customer tothe retail stores. This can be retail stores also broken down byretailer so as to have an indication of the loyalty of customers tospecific retailers For every customer, calculate the number of timeshe/she visited a certain store over a certain period Averaging the abovecalculated figure across all customers per store will give Averagenumber of visits per customer per store Customer: number/rate of Similarto the ratio of redeemed to activated coupons coupon redemptions (if Thenumber of coupons redeemed by a specific customer/ most coupons expireor sit number of activations of this customer unused) Customer: $ amountof Savings per customer. Along with the number of coupons per couponredemptions customer this is an indication of the value of each customerto the distributor The sum of all the discounts due to the coupons thata customer used Customer basket metrics Mentioned Above-inclusive of $,#items, categories etc., number of baskets, trips etc. Number of uniqueretailers Mentioned Above (return trips to retail stores) visited by acustomer For every customer, calculate the number of unique retailersvisited over a certain period Number of unique The number of uniquecustomers per coupon is a measure of the customers redeeming apopularity of each coupon. coupon For every coupon, Calculate the numberof unique customers redeemed it over a certain time period

4.9. Example Associative Analysis/Association Scoring

The examples below illustrate just some of the wide variety ofassociation analysis and scoring functions and that may be utilized topractice the techniques described herein. Many variations on thesefunctions and alternative functions are possible. Many embodiments ofthe described techniques do not require any specific scoringfunction(s), but instead may utilize any suitable scoring function(s).

Association Analysis (or Item-to-Item Collaborative Filtering)

In an embodiment, a recommendation system uses the transaction data toidentify baskets and recognized item groups that are frequentlypurchased together. Using this information, the recommendation systemmay then generate item to item (product) recommendations. For everyproduct within a basket the recommendation system can recommend productsthat are usually purchased together with that one. Thus, therecommendation system may generate a set of recommendations for everyproduct and every basket.

In an embodiment, the recommendation system employs an associationanalysis that focuses on the identification of pairs or even sets ofproducts that are purchased together. Its main objective is to identifyhidden associations between products that cannot be traced with bareeye. To do so, customer baskets are analyzed and the significance ofeach item set is estimated using an appropriately chosen scoringfunction. Typical scoring functions in traditional association analysisare support count, support, confidence, and cosine metric. In anembodiment, all these metrics are computed and their performance isevaluated. Other metrics are also estimated including Mutual Informationand Pearson Correlation.

In the functions described herein, the operator |•| denotes the numberof elements in a set, t_(i) is a transaction that consists of severalitemsi_(k), T={t₁, t₂, . . . t_(N)} is the set of all transactions andI={i₁, i₂, . . . i_(d)} is the set of all available items.

In an embodiment, one scoring function is the geometric mean of theunique users that have purchased a specific set of items, weighted by arecency factor that aims to boost recent over outdated recommendations.

${{scoring}\left( {i_{k},i_{m}} \right)} = {\left( \frac{t_{av} - t_{0}}{t_{1} - t_{0}} \right)^{n} \times \sqrt{{{uniqueUsers}\left( {i_{k},i_{m}} \right)} \times {\sigma \left( {i_{k},i_{m}} \right)}}}$

In the above equation, the variable t_(av) is the weighted average ofthe times that this specific pair of items has been purchased, or:

$t_{av} = {\sum\limits_{m = 0}^{M}\; {w_{m} \times t_{m}}}$

The variable t₀ is the time of the first purchase in the data set. n≧2indicates the nonlinear effect on the weighting. Weighting can beperformed taking into account the number or the dollar value of thesepurchases.

A variation of this metric is the following

${{scoring}\left( {i_{k},i_{m}} \right)} = \sqrt{{{UniqueUser}\left( {i_{k},i_{m}} \right)} \times {\sum\limits_{m = 0}^{M}\; \left( \frac{t_{m} - t_{0}}{t_{1} - t_{0}} \right)^{n}}}$

In the above equation, the time effect of recommendations is accountedby replacing the support count term in the square root with the sum ofall the recency factors.

Finally extensions of this scoring function may include price weightingand geographical weighting:

${{scoring}\left( i_{k}\rightarrow{i\_ m} \right)} = {w_{price}\sqrt{w_{geo} \times {{UniqueUser}\left( {i_{k},i_{m}} \right)} \times {\sum\limits_{m = 0}^{M}\; \left( \frac{t_{m} - t_{0}}{t_{1} - t_{0}} \right)^{n}}}}$

In the above, equation, w_(price) and w_(geo) are nonlinear weightingfactors that take into account the relative price of items i_(k) andi_(m) and also the relative distance between the place where the placewhere the purchase of the pair takes place and the location where therecommendations are going to be provided.

In another embodiment, an association score may be calculated asfollows:

${{scoring}\left( {i_{k},i_{m}} \right)} = {w_{price} \times \left( \frac{{Price}_{k}}{{Price}_{m}} \right)^{l} \times \sqrt{w_{geo} \times {{UniqueUser}\left( {i_{k},i_{m}} \right)} \times {\sum\limits_{m = 0}^{M}\; \left( \frac{t_{m} - t_{0}}{t_{1} - t_{0}} \right)^{n}}}}$

In yet another embodiment, an association score may be calculated asfollows:

${{scoring}\left( {i_{k},i_{m}} \right)} = {\left( \frac{t_{av} - t_{0}}{t_{1} - t_{0}} \right)^{n} \times \left( \frac{{Price}_{k}}{{Price}_{m}} \right)^{l} \times \sqrt{{{uniqueUsers}\left( {i_{k},i_{m}} \right)} \times {\sigma \left( {i_{k},i_{m}} \right)}}}$

In yet another embodiment, an association score may be calculated asfollows:

${{scoring}\left( {i_{k},i_{m}} \right)} = {\left( \frac{t_{av} - t_{0}}{t_{1} - t_{0}} \right)^{n} \times \left( \frac{{Price}_{k}}{{Price}_{m}} \right)^{l} \times \sqrt{{{uniqueUsers}\left( {i_{k},i_{m}} \right)} \times {\sigma \left( {i_{k},i_{m}} \right)}}}$

In this embodiment, the recency effect is controlled by factor n and theprice effect is controlled by factor 1.

Collaborative Filtering (Customer-to-Item Collaborative Filtering)

The full transaction history of every customer can be extracted fromtransaction data. This can then be used for the application ofcollaborative filtering techniques. These techniques attempt to find forevery customer, customers with similar purchasing behavior,characteristics and purchasing patterns, and preferences. Thenrecommendations for a customer are generated by identifying the mostfrequent purchases of similar customers.

The similarity among customers can be defined in several fashions. Oneapproach is to compare the record of every customer to the records ofthe other customers in the CAR and to generate a similarity index. Thisindex should be frequently updated as customers are dynamic entitiesthat continuously purchase new items and thus continuously alter theirpreferences and behavior as this is recorded in the CAR. This process isvery accurate but also very computationally intense, since it requires Nby N comparisons, where N the number of customers. Another approach isto apply micro-clustering techniques to group customers into segments ofusers with like behavior and to generate recommendations for a customerusing the purchases of his peers within the same group. This approach isless computation intense but less accurate than the former one.

OTHER EXAMPLES

In an embodiment, a recursive computation of association scores isperformed to reduce computational complexity. In the below equation,“week” may be generalized to any arbitrary time period, depending on theembodiment.

TotalScore(i _(k) ,i _(m),week_(l))==a×TotalScore(i _(k) ,i_(m),week_(l)−1)+(1−a)×Score(i _(k) ,i _(m),week_(l))

4.10. Example Universal Scoring Functions

FIG. 26 depicts an example flow 2600 for calculating a universal score,according to an embodiment.

Block 2610 comprises counting impressions of offers provided by an offerserver. Block 2612 comprises counting activations of offers provided byan offer server. Block 2614 comprises counting redemptions of offersprovided by an offer server. For example, blocks 2610-2614 may involveanalyzing logs of the various offer-related activities conducted by anoffer server and various transaction logs, as described in othersections. Or, blocks 2610-2614 may simply comprise maintaining runningcounters of impressions and activations for each offer.

Block 2620 comprises identifying a set of offers responsive to arequest. The request may be any request that is responded to at leastpartly with one or more offers. The request may or may not includecontext data. The offers may be identified using any suitable search,matching, and/or filtering techniques including those describedelsewhere in this application. In an embodiment, all available offersare in the set of offers.

Block 2630 comprises determining the total number of activations for aparticular offer. Block 2632 comprises calculating the average totalnumber of activations for a plurality of offers. The plurality of offersmay be all offers distributed by an offer server, all offers identifiedin response to the request, or all offers in a category of offersindicated by the request. Block 2634 comprises calculating a first ratioof the total number of activations for the particular offer to theaverage total number of activations for the plurality of offers.

Block 2640 comprises determining the total number of impressions for theparticular offer. Block 2642 comprises calculating the average totalnumber of impressions for the plurality of offers. Block 2644 comprisescalculating a second ratio of the total number of impressions for theoffer to average total number of impressions for the plurality ofoffers.

Block 2650 comprises determining the total number of redemptions for theparticular offer. Block 2652 comprises calculating the average totalnumber of redemptions for the plurality of offers. Block 2654 comprisescalculating a third ratio of the total number of impressions for theoffer to average total number of redemptions for the plurality ofoffers.

Block 2660 comprises calculating the universal score for the particularoffer as a function of the first ratio, second ratio, and third ratio.Various example functions are described subsequently.

Block 2670 comprises repeating blocks 2630-2660 for each offer in theset of offers.

Block 2680 comprises ranking the set of offers based at least in part onthe universal scores.

Block 2690 comprises providing information about at least a subset ofthe ranked set of offers in response to the request, using any of thevarious techniques described herein. For example, the information may beembedded in a web page or receipt. Or, as another example, theinformation may be formatted as XML or JSON data for a coupon-viewingsmartphone or browser application.

Blocks 2630-2670 may be relative to a particular consumer to whom therequest is resolved, a group of consumers identified by the request orof whom such a particular consumer is a member, or all consumers thataccess the offer server.

Flow 2600 is but one example technique for calculating a universalscore. Other techniques may comprise fewer or additional elements, inpotentially varying orders. For example, the calculating of block 2660may be based further on a burn rate which considers the start date of anoffer, the end date of the offer, and the inventory of activations orredemptions remaining for that offer. As another example, in anembodiment, some or all of the first, second, and third rations areassigned weights. In an embodiment, these weights may be learned basedon feedback mechanisms, such as actual revenues over a certain periodfor a retailer, provider, or offer distributor, as calculated from thevarious transaction and/or offer logs. In an embodiment, the weights mayvary depending on the context of the request. For example, the weightsmay be different for requests from desktop applications as opposed tomobile applications. Or the weights may be different for differentconsumers.

It is possible that newer offers may lack meaningful data concerningactivations, redemptions, and impressions. In an embodiment, any or allof the first ratio, second ratio, and third ratio for newer offers maybe replaced with statistics from similar offers or with categoricalaverages until meaningful data is available for the newer offers.

In an embodiment, a universal scoring function is as follows:

${UniSc} = {\begin{pmatrix}\begin{matrix}{{w_{A} \times \frac{activations}{{average}\mspace{14mu} {Activations}\mspace{14mu} {per}\mspace{14mu} {Coupon}}} +} \\{{w_{B} \times \frac{impressions}{{average}\mspace{14mu} {Impressions}\mspace{14mu} {per}\mspace{14mu} {Coupon}}} +}\end{matrix} \\{w_{C} \times \frac{redemptions}{{average}\mspace{14mu} {Redeptions}\mspace{14mu} {per}\mspace{14mu} {Coupon}}}\end{pmatrix} \times \frac{\left( {{InitialInventory} - {Activations}} \right)}{InitialInventory} \times \frac{\left( {{ExpiryDate} - {CurrentDate}} \right)}{{CurrentDate} - {StartDate}}}$

In this function, the historical performance of every offer is comparedto the average offer performance in three dimensions: activations,redemptions and impressions. Each dimension is weighted differently soas to reflect its importance and match the score to strategicobjectives. This weighted comparative score is weighted with thepercentage of the inventory that is still unused and the offer remainingactive days. This metric is relative since it compares the performanceof each offer to the average offer performance. Offers with performancebetter that the mean performance are preferred. Offers with largerinventory and/or more active days are promoted more.

This function may be useful in contexts where it is important tocarefully manage activation, impression, and redemption velocity andpopularity, inventory levels (more inventory, the higher the value), andoffer runaway (the more available time the more value). Potentialchallenges in using this function include the fact that the functiondoes not focus on close out of existing non-performing offers, andplaces less explicit emphasis on pricing model.

In another embodiment, a universal scoring function is as follows:

${UniSc}_{alt} = {\frac{Revenues}{\left( {{CurrentDate} - {StartDate}} \right) \times {Impressions}} \times \left( {{EndDate} - {StartDate}} \right) \times \left( {{InitialInventory} - {NumberOfActivations}} \right)}$

This function may be useful in contexts where it is important tocarefully manage activation and impression velocity and popularity,inventory levels, offer runaway, explicit revenue generated to the offerdistributor for the offer, and future weighting of that value. Potentialchallenges in using this function include the fact that the functiondoes not focus on close out of existing non-performing offers, does notseparate manual activation and auto activation, and that handling ofzero-economic-events require surrogate revenue value.

In another embodiment, a universal scoring function is as follows:

${UniSc}_{alt} = {\frac{{ManualActivations} \times {RPA}}{\left( {{CurrentDate} - {StartDate}} \right) \times {Impressions}} \times \left( {{EndDate} - {StartDate}} \right) \times \left( {{InitialInventory} - {NumberOfActivations}} \right)}$

RPA stands for the revenue per activation. This function may be usefulin contexts where it is important to carefully manage impression andmanual activation velocity and popularity, inventory levels, offerrunaway, explicit revenue generated to the offer distributor for theoffer, and future weighting of that value. Potential challenges in usingthis function include the fact that the function does not focus on closeout of existing non-performing offers or auto activation, and thathandling of zero-economic-events require surrogate revenue value.

In another embodiment, a universal scoring function is as follows:

${UniSc}_{alt} = {\frac{{ManualActivations} \times {RPA}}{\left( {{CurrentDate} - {StartDate}} \right) \times {Impressions}} \times \left( {{EndDate} - {StartDate}} \right) \times \left( {{InitialInventory} - {NumberOfActivations}} \right)}$  or ${UniSc}_{alt} = {\frac{\begin{matrix}{{{ManualActivations} \times {RPMA}} +} \\{{AutoActivations} \times {RPAA}}\end{matrix}}{\left( {{CurrentDate} - {StartDate}} \right) \times {Impressions}} \times \left( {{EndDate} - {StartDate}} \right) \times \left( {{InitialInventory} - {NumberOfActivations}} \right)}$

RPAA and RPMA stand for revenues for auto-activations and manualactivations, respectively. This function may be useful in contexts whereit is important to carefully manage impression, manual Activation,and/or auto activation velocity and popularity, inventory levels, offerrunaway, explicit revenue generated to the offer distributor for theoffer, and future weighting of that value. Potential challenges in usingthis function include the fact that the function does not focus on closeout of existing non-performing offers, has high computational overhead,and that handling of zero-economic-events require surrogate revenuevalue.

In another embodiment, a universal scoring function is as follows:

${UniSc}_{alt} = {\frac{TotalRevenue}{\left( {{CurrentDate} - {StartDate}} \right) \times {Impressions}} \times \left( {{EndDate} - {StartDate}} \right) \times \left( {{InitialInventory} - {NumberOfActivations}} \right)}$  Where${TotalRevenue} = {{\sum\limits_{{Manual}\mspace{11mu} {Act}}^{\;}\; {RPMA}_{i}} + {\sum\limits_{{Auto}\mspace{11mu} {Act}}^{\;}\; {RPAA}_{i}} + {Sponsorship}}$

The historical performance of every offer is assessed by considering therevenue an offer has generated over all consumers, the period that theoffer is active, and the number of impressions that were incurred. Thesenumber yield an “adjusted burn rate.” The adjusted burn rate ismultiplied with remaining period and remaining inventory to get anestimate of the additional revenue this offer can generate. Offers thathave generated high revenues are preferred. All others being equaloffers that achieve high revenues in short times are preferred alongwith offers that perform high performance with less impressionsrevealing a momentum. This approach allows for complicated pricingmodels and accounts for offer sponsoring too. However, this approachalso has a feedback issue: sponsoring an offer will increase itsimpressions. However, if the offer revenues will not increase, itsuniversal score will drop again.

This function may be useful in contexts where it is important tocarefully manage impression, manual Activation, and/or auto activationvelocity and popularity, inventory levels, offer runaway, explicitrevenue generated to the offer distributor for the offer, and futureweighting of that value, while also providing a sponsorship boostcapability. Potential challenges in using this function include the factthat the function does not focus on close out of existing non-performingoffers, has high computational overhead, associates revenue withsponsorship, and that handling of zero-economic-events require surrogaterevenue value.

In another embodiment, a universal scoring function is as follows:

${{scoring}\left( {i_{k},i_{m}} \right)} = {\left( \frac{t_{av} - t_{0}}{t_{1} - t_{0}} \right)^{n} \times \log \frac{TotalActiveConsumers}{{ConsumersPurchased}\left( {i_{k},i_{m}} \right)}\sqrt{{{uniqueUsers}\left( {i_{k},i_{m}} \right)} \times {\sigma \left( {i_{k},i_{m}} \right)}}}$

This function may be useful in contexts where it is important to, amongother aspects, avoid best-sellers being over-recommended.

In an embodiment, a recommendation may integrate association scores withuniversal scores when ranking offers. A new, financially weighted scoreis produced:

AREScore_(new)=Score(Item_(i),item_(j))×UniSc_(alt)(item_(j))^(n)

, with Score (item_(i),item_(j)) the scoring of the (item_(i),item_(j))association and

UniSc_(alt)(item_(i)) the Universal Score (the projected financialvalue) of item_(j). The power n is used as a switch: when n=0 then theuniversal score is not taken into account, which with n>0 it is takeninto account and the greater n becomes, the more important thecontribution of universal scoring is. Having a provider sponsoring acoupon with a lump sum would result in an increase in its UniversalScore since the revenue term in the numerator will increase.Subsequently this will result in the coupon being recommended more oftenand in higher ranks.

4.11. Example Filtering of Offers

In order to render derived recommendations more effective, more targetedand also to cater for existing limitations and business requirement, thegenerated recommendations may optionally be post-processed usingpre-defined business rules. Examples of business rules are: promotespecific items by increasing their ranking in the recommendations ruleset; avoid specific items completely; target specific customers with oneoff promotions; constrain recommendations to avoid overlap with otherconcurrently running promotions; limit recommendations to certaincategories, or spread recommendations to cover a more diverse range ofcategories.

In an embodiment, a filter checks that a shopper has not alreadyactivated an offer, which may otherwise have been recommended in adigital receipt, online gallery, and so forth based on the algorithm'sscoring. The filter prevents double-dipping of the offer. In anembodiment, the offer server is configured to not offer or auto-activateoffers for items that are currently out of stock. In an embodiment, theoffer server is configured to not offer or auto-activate offers thathave reached their activation (distribution) limit. In an embodiment,the offer server is configured to not offer or auto-activate offers thatare past the offer shutoff period.

In an embodiment, non-auto-activated offers on digital receipts will beplaced on hold for a certain period of time to guarantee that they areavailable for the targeted consumer for activation. However, if thenon-auto-activated offer hold has expired on the digital receipt, thenthe consumer will be notified that the offer is no longer available.

One example business rule concerns a manually-targeted offer for which aprovider has “purchased a spot” on the digital receipt. Therecommendation engine may rank the offer above the auto-targeted offers,even if the auto-targeted offers have a better fit for the consumer.Another example business rule concerns a consumer who fits criteria fortwo or more manually-targeted offers. The recommendation engine may takethe average or weighted average of RPI and RPR for the offers and rankthe offers based on the results.

4.12. Auto-Activation Rules

In an embodiment, various rules established by the offer distributor oroffer provider may allow for offers to become auto-activated. When anoffer is auto-activated for the consumer, the consumer may redeem theoffer without ever affirmatively requesting access to the offer.However, the consumer may still be notified that the offer has beenactivated for the consumer. In an embodiment, a certain number oftargeted or recommended offers are automatically activated for eachreceipt presented to a consumer and/or each request for offerrecommendations. However, since an activated offer counts as adistributed offer, offer distributors and offer providers may wish to beconservative with auto-activation rules, to avoid running out of offerstoo quickly and/or diluting the effectiveness of activations in general.Other example auto-activation rules are as follows.

Global rules may include rules for adjust the count of auto-activatedoffers on individual digital receipts (e.g. from 0 to 5), both globallyand for only a subset of consumers based on predefined conditions.Consumer-specific rules may include rules for turning on or off theauto-activation capability for only a subset of consumers based onpredefined conditions, rules to prevent auto-activations for consumerswho have not looked at any requested digital receipts in a previousperiod of time (e.g. the past 60 days), and rules to preventauto-activations for consumers who have had more than a certain numberof offers (e.g. 20) auto-activated in a previous period of time (e.g. 30days) without any redemptions. Offer-specific rules include rules forspecifically auto-activating offers with a high propensity forredemption (i.e. offer that have an above average redemption rate),rules to over-ride a “best for consumer” ranking with a “best forredemption” ranking, and rules to only auto-active offers for productsthe consumer has been shown to regularly purchase.

One example auto-activation rule concerns a manually-targeted offer thatfits better than any of the auto-targeted offers. The recommendationengine determines that the manually-targeted offer fits the consumerbetter and placed the manually-targeted offer above the auto-targetedoffers. If the manually-targeted offer is within the top three, it couldbe auto-activated.

4.13. Events and Triggers

In an embodiment, example elements of target contexts to which offersmay be targeted include some or all of: “best customers,” specificdemographic groups, item(s) just purchased, item(s) in a shopping list,item(s) in a purchase history, offer(s) is an offer history,revenue-per-impression based score(s), revenue-per-activation basedscore(s), revenue-per-redemption based scores(s), customer requests tocompare items, frequency of purchase based score(s), propensity-to-buybased score(s), shopping location(s), basket value, basket breadth,specific brand(s) purchased, specific search term(s), retailoccasion(s), best-fit score(s), specific web page visits, scanneditem(s) using a smartphone, scanned item(s) while in a store, timeand/or date, current location(s), predefined consumer profiles, and soforth.

In an embodiment, a workflow for a provider creating a target contextcomprises selecting a target type, such as customer, selecting a nameand/or privacy level for the target, and selecting target criteria. Acriteria workflow construction component lists available criteria in anumber of categories, and the provider is allowed to select one or moreof these criteria for the context. Subsequent to creating targets, theprovider may access a list of targets, edit those targets, and reviewreporting analytics such as graphs and charts.

4.14. Target Treatment Groups

In an embodiment, a provider may create target treatment groups, inwhich different types of visuals or monetary discounts are given to asame target group. For example, the provider has the ability to select atarget from a list of defined targets, such as “Frequent Frozen PizzaBuyers,” “Frozen Foods—High,” or “Top 50% Baby Care Customers.” Theprovider is then given the ability to select from a list of offers toassociate with the target. If the target does not include multipletreatments, then there will be a 1:1 offer to target match. If the userdesires to create multiple treatments for a manual target, they canselect the ability to apply treatments and enter in the treatment foreach of treatment groups. A target treatment group will be created byeither allocating a certain percentage or a defined number of customers.This allocation will randomly assign a customer to a treatment groupbased on the criteria.

Another group may be created which will represent a control group. Thisgroup will not have offers associated with it. Each target treatmentgroup can have a unique offer associated with it. Once a target ortarget treatment group is associated with an offer, this can then besaved and results are saved into a database table. A provider can set aUniversal Score to an offer/target association which will determine howa manual target is treated when integrated with automated targets.

The table below illustrates an example target treatment group.

% Size Offer Score Group A 33 165,000 $1.50 off Product 98 Group B 33165,000 $2.00 off Product 98 Group 3 33 165,000 Control 98

4.15. Customer Value

In an embodiment, a customer value score may be used for a variety ofpurposes, including, without limitation, ranking customers, creatingcustomer segments for reporting and offer targeting, and/or dynamicallyadjusting the price of an item or amount of an offer based on usercredentials. For example, a store may use the customer value score toidentify a group of high value customers to whom to target an offer. Asanother example, in an embodiment, an offer amount is a function of thecustomer value score of the customer who activates it.

In an embodiment, the score comprises a sales component, activationcomponent, frequency component, recency component, and/or averagecategories shopped component. The score is a function of a numeratorbased on the individual user and denominator is based on the average ofall users. In other embodiments, the CVI calculation may be modified totake the following into consideration other factors such as redemptions,impressions, dollar amount per basket, and number of offers per basket.

In an embodiment, each component is weighted. For example, the salescomponent may be weighted at 25%, the activation component at 35%, thefrequency component at 15%, the recency component at 15%, and theaverage categories shopped component at 10%.

In an embodiment, the customer value score is comprised on multipleperformance measures that are weighted to a single performance metric.The result is a weighted sales dollar value that incorporates allperformance measures. Weightings of the measures can be adjusted toreflect the values of the retailer.

In an embodiment, a customer value score is calculated for each customerover a twelve month period. All components are calculated over theentire time period available in the database (up to a full 12 monthperiod) except for Recency, which is calculated over a smaller timeperiod, last 4 weeks.

Example calculations for the various components may be as follows:

  Sales = Sales  Weight × $ Sales${Activations} = {{Activations}\mspace{14mu} {Weight} \times \frac{{Number}\mspace{14mu} {of}\mspace{14mu} {Activations}}{{Avg}\mspace{14mu} {Number}\mspace{14mu} {of}\mspace{14mu} {Activations}\mspace{14mu} {for}\mspace{14mu} {all}\mspace{14mu} {Shoppers}} \times \$ \; {Sales}}$${Frequency} = {{Frequency}\mspace{14mu} {Weight} \times \frac{{Basket}\mspace{14mu} {Count}}{{Avg}\mspace{14mu} {Basket}\mspace{14mu} {Count}\mspace{14mu} {for}\mspace{14mu} {all}\mspace{14mu} {Shoppers}} \times \$ \; {Sales}}$${Recency} = {{Recency}\mspace{14mu} {Weight} \times \frac{{Basket}\mspace{14mu} {Count}\mspace{11mu} \left( {{last}\mspace{14mu} 4\mspace{14mu} {weeks}} \right)}{{Avg}\mspace{14mu} {Basket}\mspace{14mu} {Count}\mspace{14mu} \left( {{last}\mspace{14mu} 4\mspace{14mu} {weeks}} \right)\mspace{14mu} {for}\mspace{14mu} {all}\mspace{14mu} {Shoppers}} \times \$ \; {Sales}}$${{Average}\mspace{14mu} {Categories}\mspace{14mu} {Shopped}} = {{Avg}\mspace{14mu} {Categories}\mspace{14mu} {Shopped}\mspace{14mu} {Weight} \times \frac{{Avg}\mspace{14mu} {Categories}\mspace{14mu} {Shopped}}{{Avg}\mspace{14mu} {Categories}\mspace{14mu} {shopped}\mspace{14mu} {across}\mspace{14mu} {all}\mspace{14mu} {Shoppers}} \times \$ \; {Sales}}$

For reports that require metrics to be defined as indexes, a customervalue index may be used.

$\frac{CV}{{Avg}\mspace{14mu} {CV}\mspace{14mu} {for}\mspace{14mu} {all}\mspace{14mu} {Customers}}$

In an embodiment, the customer value is updated periodically, such asweekly. In an embodiment, customers are sorted by value into groups,such as deciles, by which they may be referenced in other contextsdescribed herein, such as targeting or reporting.

4.16. Example Recommendation API

An example API for interfacing with a recommendation engine, accordingto an embodiment, exposes recommendation methods using the SOAPprotocol. Other protocols may be used for other APIs, including withoutlimitation JSON, XML, and so forth.

An example API call is getRecommendations(String accountName, StringcustomerKey, Item[ ] items, RecommendationContext context), whichreturns Item[ ] recommendationItems. This call returns recommendationsgenerated for a customer for the specified recommendation context. Forunknown customers, the customerKey should be set to “ ”. If the customeris not known, or if the recommendation engine has yet to generaterecommendations for a newly registered user, the service will still makea best attempt at providing a recommendation, for example by providingnon-personalized recommendations. items should be a list of products orservices relevant to the RecommendationContext specified by context.Similarly, when an unknown item is provided in the list of items, thatitem is silently ignored.

In an example environment, the accountName is synonymous with thePartner.partnerId, while the customerKey is synonymous with theUser.userId, the unique identifying key of a customer completing thetransaction. The number of items returned may be dependent on thecontext as they reflect different recommendation algorithms on thebackend. The recommendation context is a hash or record that specifiesvarious attributes that represent the recommendation context. Arecommendation context may include a string or other identifierspecifying the context. Some examples of recommendation contexts are:digital receipts, digital receipt histories, various sections of onlinewebpages, footers at the bottom of customer emails, shopping cartcheckout pages, shopping lists, kiosks, SMS messages, coupon gallery,item detail page, and so forth. The context indicates the meaning of theItems array (e.g. a shopping list, a currently viewed item, an itemhistory, etc.). Other attributes may include, without limitation, anumber of recommendations expected for the context, a number of offersto auto-activate, geolocation, time zone, screen size, ip address, storeid, check-out counter, and so forth.

Another example of a suitable API call is an explainRecommendationscall, which is similar to getRecommendations except an explanation ofreason(s) why the recommendations were made is also provided.

4.17. Example Identification of Consumers

In an embodiment, at a retailer where loyalty system is in place, aconsumer is identified using a loyalty card identifier. A new userrecord will be created if the loyalty card identifier is not found inthe existing database. Any provided mobile number or email for a digitalreceipt may be tied to the loyalty card identifier in the database. Acredit/debit card hashed value may be tied to the loyalty cardidentifier if a credit/debit card is used. In an embodiment, at aretailer without a loyalty system, a consumer is identified through aPAN, phone number, or email address. Other retailers may have otheridentification mechanisms.

A new consumer record is created if a user requests a digital receiptwithout using, for example, a loyalty card identifier or account number.The record is created using a combination of an email or mobile numberwith a PAN, if used. In an embodiment, the consumer specifically opts-into the digital receipt system before a new consumer record is created.If the consumer has not opted-in, or does not provide identifiers suchas listed above, the transaction log may be discarded, or at leastignored for algorithms and analytics that would require resolution ofthe consumer entity.

Consumer Resolution Interface

An offer distributor or other entity may provide a consumer-resolutionservice to assist in the identification of a consumer at a retailersystem for digital receipt and other purposes. The retailer can usethese services to also identify a consumer in the absence of a loyaltyprogram. The search for a consumer is a real-time request against aconsumer resolution server process that communicates with a consumerdata store. There may be multiple options for accessing the consumerresolution service. The service may be externally hosted by the offerdistributor, or hosted at the retailer's data center based on cachedconsumer data, or directly integrated into the retailer's CRM system.

For example, a standalone instance of the consumer resolution servicecan be deployed into the retailer's data center through a local serviceto be directly accessed by the store. This Local service isautomatically synchronized with the central consumer data store. Thisapproach can be used when changes to the retailer's CRM solution are notpossible, or security or operational polices prefer internally hostedsystems.

As another example, a retailer system can access a consumer resolutionservices API hosted by the offer distribution system, directly in realtime. With this option there is only one source of consumer data. Thusdata synchronization is not necessary.

As another example, integration of consumer preferences and otherconsumer data directly into the retailer's existing CRM solution allowsfor reuse of existing interfaces. However it requires customization ofthe retailer CRM for storage and modification of interfaces. A batchprocess would be responsible for the synchronization of consumerpreferences between the retailer CRM against the consumer data store. Alimitation of this approach is possibility of inconsistent informationfor short periods of time while synchronization is in progress. Whensuch customization to the retailer's CRM solution is not possible orpractical, the retailer may choose to call externally to the offerdistributor's hosted consumer resolution service, or deploy an instancewithin their data center.

4.18. Example Consumer Record Correlation Rules

In an embodiment, master records are generating during the initialloading and/or batch updates of customer records from retailers and/orother partners based on the following correlation rules, which areprocessed in sequential steps. Each sequential step is performed onlyfor records that the previous step fails to match.

First, if records contain the same email address, and the email has notbeen blacklisted, the records are correlated together as one mastercustomer record. Second, if records contain the same mobile or otherphone number, and the same last name, the records are correlatedtogether as one master customer record. Third, if records contain thesame first name, last name, and PAN, the records are correlated. Fourth,if records contain the same loyalty number for a same retailer, therecords are correlated. Fifth, if records match on a phone number and ahashed credit/debit card value, the records are correlated.

In all of the above, one of the sources of the matched records should bea source that has been designated as a “primary” or highly trustworthysource. Also, when merging records to form a master record,contradicting field values are both stored in the database, and a“primary” flag is set for the fields based on a source hierarchyestablished based on trustworthiness.

Example default trust scores for establishing a source hierarchy withrespect to the fields of the sources are illustrated in the followingtable. Each column represents a different source of customer records,such as periodically uploaded retailer customer records from a loyaltyprogram, raw customer records built from unique combinations ofcredentials in transaction data, and so forth. A lower score is better.

Credit Digital Receipt Distributor Retailer Third Card TransactionRegistration Loyalty Party Data Data Data Card Data Data First Name 1N/A 2 3 4 Last Name 1 N/A 2 3 4 Email 2 1 3 4 5 Mobile 2 1 3 4 5 NumberBilling 1 N/A 2 3 4 Address Mailing 2 N/A 1 3 4 Address Birth date 1 N/A2 3 4 PAN 1 2 N/A N/A 3 Loyalty N/A 2 1 2 N/A Number

Similar rules may be used for correlating transactions both to eachother and to existing customer records, since transactions also includethe fields listed above. In an embodiment, the above rules constitutebut a first phase of correlation. Additional phases may rely on othercorrelation rules or mechanisms.

4.19. Example Reports

In an embodiment, a provider may access the following example reports.

Distributor Metrics Key performance metrics for coupons, revenue,customers and redemptions Retailer Metrics Retailer specific keyperformance metrics specific for coupons, revenue, and customersCPG/Client Metrics Shows CPG/Client specific key performance metricsspecific for coupons, revenue, and customers Customer Metrics ShowsCustomer key performance metrics Marketing Effectiveness Shows Clientcoupon statistics, inventory and redemptions (Promotion Types) Comparesthe effectiveness of promotion types (advertisements, offers). CouponPerformance Interactive dashboard on coupon performance, as well asunderstanding what is driving these results for the various activationmethod by category, channel, provider (CPG), and retailer RetailerCoupon Similar interactive dashboard, specific to retailers PerformanceCPG/Client Coupon Similar interactive dashboard, specific to providersPerformance Customers Interactive dashboard on customers thatfacilitates an understanding of the customer behavior for specificoffers, categories, retailers, and so forth. Customer TargetingInteractive dashboard on customer targeting for identifying andtargeting a specific group of customers for an offer. This targetingprocess can also be enhanced by applying a specific strategy to thetargeting approach. Sales Targeting Interactive Dashboard on SalesTargeting Cross Purchase-Retailer Interactive Dashboard on crosspurchase between items to view offer impact Cross Purchase-CPGInteractive Dashboard on cross purchase among retailers to view offerimpact Forecasting Interactive Dashboard on Forecasting Customer DecileBubble Compares performance of customers in 10 equal segments by Chartthree selected metrics. Customer Decile by Shows performance ofcustomers by category in 10 equal Category segments by customer valuefor selected time. Customer Decile Shows performance of customers in 10equal segments by Performance customer value index over time. CustomerPurchase Index Shows comparison to average (index) of productperformance for selected customer(s) to all customers. (Interactive: canselect departments and change metrics) Customer Segment Bubble Comparesperformance of customers in selected segments by Chart three selectedmetrics. Customer Segment Compares customers segments for selectedmetrics. Comparison New vs. Repeat Customers Identifies new and repeatcustomers count for selected product, by Product location and time.Customer Attributes Compares attributes of customers for selectedproduct with all products, for selected location and time. CustomerOverview Shows an overview of demographic and performance for a selectedcustomer segment. (may limit by location for retailers and limit forcategory for clients) Attribute Profile Analysis Show prevalence ofunique attributes by SKU for selected product. (may limit by locationfor retailers and limit for category for clients) Cumulative ProductShows cumulative product performance for selected product, PerformanceCurves time, location, and metric. (may limit by location for retailersand limit for category for clients) Customer Importance, by Showsimportance of products to customers (loyalty, exclusivity, Productrepeat, purchase prevalence) and volume metrics for selected productgroup, customer, location and time. Promotion Performance by Showsproduct performance for a selected promotion and Product selectedcustomer(s). (Interactive: can select categories and change metrics)(may limit by location for retailers and limit for category for clients)Promotion Performance by Shows pre, during, and post period productperformance for a Segment selected promotion and customer(s).(Interactive: can select categories and change metrics) Customer ListsMeasures the number of identifiable customers by state PromotionPercentage Breaks down customer count into 5 groups (0-20%, 20-40%, 40-Analysis 60%, 60-80%, 80-100%) based on percentage of promotional spend,for selected customer, product, location and time. Cross ProductAttachment Shows the pre-, during and post-event customer count andAnalysis attachment index for customers who bought from two productgroups (primary and comparison), for selected customer, product,location and time. Marketing Impact, by Compares product performance bycustomer segment before, Customer during, and after a selectedpromotional period, for selected customer, product, location and timeMarketing Impact, by Compares sales volume for selected customersegments for offers Customer Segment, by during selected customer,product, location and time. Offer Marketing Response Index, Compares therelative (index) performance of marketing events by Customer by customersegment. Basket Quantity Shows the number of baskets purchased (1, 2,3-5, 6-9, 10+) for selected customer, product, location, and time. (maylimit by location for retailers and limit for category for clients)Basket Size, Sales and Shows basket, total sales and average priceimpacts by product Price, by Product subcategory, for a selected event,customer, product and location. (limit by location for retailers andlimit for category for clients) Sales, Price and Customer Shows regularand promotional unit count, average price, sales Penetration, by Weekper customer and average penetration by week for selected product,customer, location and time. Top 10 Cherry Picked, Shows top 10 itemsfrom a selected marketing event that are Basket Building being boughtonly on promotion (cherry picked) or that are driving basket size(basket building) for selected event. Basket Metrics, for Two Comparesbasket metrics, for two time periods, for selected Periods customer,product and location. SKU Exception Chart Shows selected comparativemetrics by SKU. Basket Analysis, Shows the relative importance ofproducts groups (comparison) Attachment Rank Order to a selected productgroup (primary) based on rank order of cross-product attachment index.This includes customer count, units, and sales. Basket Analysis,Customer Shows the relative importance of products groups (comparison)Count Rank Order to a selected product group (primary) based on rankorder of cross-product customer count. Includes attachment index, units,and sales. Cross Product Lift Analysis Shows the pre-, during andpost-event customer count and sales for customers who bought from twoproduct groups (primary and comparison) for selected customer, product,location and time. Customer and Basket Shows sales volume, gross margin,unit count, basket count, and Scorecard, by Customer customer count forselected product group, customer, location Segment and Product and time.Customer and Basket Shows sales volume, customer count, basket count,basket size Volume, by Product index, and basket promotion index forselected product group, customer, location and time. Product PurchaseOverlap, Displays counts of customers that purchased any combination of2 Groups products for two selected product groups, for a selected time.Performance Index Chart Shows comparison to average (index) of productcategories for Customer Segments selected customer segments.(Interactive: can select categories) Performance Index Chart Showscomparison to average (index) of product categories for Store Segmentsselected store segments. (Interactive: can select categories) Price andVolume Analysis, Shows the average price, volume and % of category sales, by by Week week for selected product, customer, location and time.Customer Marketability Measures the number of identifiable customers whoare mailable, e-mailable, or phoneable. Marketing Effectiveness Showscustomer and basket metrics and lifts for a selected (Campaigns)campaign, and selected customer, product, location and time. UnitQuantity Shows the number of unit purchased (1, 2, 3, 5, 6, 9, 10+) forselected customer, product, location, and time. Basket Metrics(Promotion Compares the product's performance by shopper segment before,vs. Non), by Week during, and after a promotional period. Basket Metricsby Day and Compares basket metrics, by day and time of week, forselected Time customers, product, location, and time vs. totals.Marketing Performance, Shows comparison of the performance of marketingevents by over Time time period. Unit Quantity and Price, by Shows thenumber of unit purchased (1, 2, 3, 4, 5+), customer Week count andaverage price by week for selected customers, products, locations andtime. Marketing Basket Metrics, Compares total and promotional basketmetrics for 10 same size by Decile segments. Marketing Performance Showscomparison of the performance of marketing events on three selectedmetrics. Marketing Performance, by Shows comparison of the performanceof marketing events. Event Store Volume by Week Shows basket count andsales, this year and last year, by week for selected customer, locationand time.

4.20. Distributing Promotional Information with Receipts

In an embodiment, various techniques described herein may be used todistribute information about promotional offers in addition to orinstead of offer information. For example, a digital receipt may includeor link to promotional videos, images, or other media. The promotionsoffered may be targeted based on any of the factors described herein, orselected at random. A data repository of promotional offers may bemaintained and utilized in a manner similar to that described of thedata repository of offers. Promotional offers may or may not be mappedto specific item identifiers.

According to one embodiment, input is received specifying one or moreitems for purchase by a consumer. Based on the input, a transaction iscompleted in which the one or more items are purchased. An interfaceconfigured to accept input indicating a consumer identifier associatedwith the transaction is provided. When input indicating a consumeridentifier has been received via the interface in association with thetransaction, it is determined whether the consumer identifier isassociated with any electronic address of the consumer. When theconsumer identifier has been received and the consumer identifier isassociated with an electronic address, promotional information isprovided via the electronic address. In an embodiment, some or all ofthese elements are performed by a retail terminal at a physical store,with possible assistance from a retailer-based server. In an embodiment,servers operated by other entities, including a promotion distributor,may assist in the determining and providing.

In an embodiment, when the consumer identifier has been received and theconsumer identifier is associated with the electronic address, anelectronic receipt for the transaction is provided to the consumer viathe electronic address instead a printed receipt. The electronic receiptincludes the promotional information. When no consumer identifier hasbeen received, or when a received consumer identifier is not associatedwith any electronic address, a printed receipt is provided for thetransaction.

In an embodiment, provision of the promotional information comprisessending an email to the consumer with a link to a website at whichinformation for one or more promotional offers may be obtained. In anembodiment, the promotional information includes data describing one ormore promotional offers and one or more links by which the consumer mayuse or find further information about the one or more promotions.

In an embodiment, provision of the promotional information comprises aretailer sending transaction information and an account identifierassociated with the consumer identifier to a promotion distributor, andthe promotion distributor providing the promotional information via theelectronic address. In an embodiment, provision of the promotionalinformation comprises the retailer sending account identifyinginformation associated with the consumer identifier to a promotiondistributor. In response to sending the account identifying information,the retailer receives the promotional information from the promotionprovider. The retailer then provides the promotional information with anelectronic receipt via the electronic address. In an embodiment,providing the promotional information with the electronic receiptcomprises sending the promotional information with the electronicreceipt to a mobile device operated by the consumer.

In an embodiment, a coordinating computer is queried to determinewhether the consumer identifier is associated with a known consumeridentity. The determining of whether the consumer identifier isassociated with a known consumer identity implicitly determines whetherthe consumer identifier is associated with any electronic address of theconsumer.

In an embodiment, transaction information is received for a transactionbetween a retailer and a consumer, the transaction information includingaccount identifying information. An account associated with the accountidentifying information is identified. An electronic receipt isgenerated based on the transaction information. The electronic receiptis provided with promotional information via an electronic addressassociated with the account. In an embodiment, the promotionalinformation and electronic receipt are provided by a retail server, withpossible assistance from a promotions server in identifying the one ormore promotional offers. In an embodiment, the promotional informationand electronic receipt are provided by a promotions distributor or otherentity that is separate from the retailer.

In an embodiment, providing the electronic receipt with the promotionalinformation via the electronic address comprises: sending an email tothe electronic address, the email including a link configured to send alogin request to a server; receiving, at the server, the login requestfrom a client; receiving, at the server, in association with the loginrequest, credentials corresponding to the account; and in response tothe server receiving the login request and the credentials, sending theelectronic receipt and promotional information to the client.

In an embodiment, the electronic address is one of an email address, aphone number, a social networking address, or a uniform resourcelocator. In an embodiment, selection of the one or more promotionaloffers is based on factors that do not target the behavior of theconsumer. In an embodiment, selection of the one or more promotionaloffers is based upon one or more of: the one or more items involved inthe transaction, transaction information, consumer preferences, retailerpreferences, consumer purchase history, or consumer promotion redemptionhistory. In an embodiment, upon selecting the one or more promotionaloffers, one or more digital coupons for the one or more promotionaloffers are automatically saved to the consumer's account. In anembodiment, the consumer identifier is one of a consumer loyalty cardnumber, credit card number, radio-frequency identifier (“RFID”),hardware address, or phone number.

In an embodiment, the method is performed by an entity other than theretailer. Second transaction information is received for a secondtransaction between a second retailer and the consumer, the secondtransaction information including second account identifyinginformation. The account is identified as being associated with thesecond account identifying information. Second promotional informationis provided via the electronic address associated with the account. Thesecond promotional information may be the same as, or different from,the original promotional information. In an embodiment, the secondpromotional information is provided with a second and differentelectronic receipt generated based on the second transactioninformation.

4.21. Providing Offers at ATMs and Other Devices

In an embodiment, an offer provider or distributor may contract with anATM owner or provider to provide offers at the ATM. The ATM is connectedto an offer server. While interacting with a consumer, the ATM transmitsinformation about the consumer, including one or more of debit carddata, biometric data, a phone number, email address, or deviceidentifier for a smartphone. The consumer information provided by theATM may be collected explicitly from consumer input, derived fromconsumer input based on bank records, or collected without theconsumer's explicit input from various sensors. Based thereon, and basedfurther on information such as the location of the ATM and the time ofday, the offer server resolves the consumer to a consumer entity that ismost likely to be the consumer.

The offer server may then perform one of several acts. The offer servermay, for example, automatically activate an offer for the resolvedconsumer entity. The offer server may also or instead send offer data tothe ATM, which the ATM then displays within the main ATM interface, orin a separate window or screen. The ATM may optionally wait to displaythe offer data during a time when it is processing the transaction,particularly if the offer data is displayed within the main ATMinterface.

If the offer server is not configured to automatically activate theoffer, the ATM may optionally display an interface asking the consumerto indicate whether the consumer would like to receive a coupon for theoffer. The interface may be configured to wait for consumer input. Insome embodiments, the consumer's failure to respond during a certaintime may be taken as an indication that the consumer is interested in anoffer. In other embodiments, the consumer's failure to respond during acertain time may be taken as an indication that the consumer is notinterested in an offer. In an embodiment, the timeout period expires ata time relative to when the ATM finishes processing the transaction.

In an embodiment, if the consumer indicates that the consumer isinterested in receiving a coupon for the offer, the ATM may either printa coupon for the consumer. The coupon may or may not be on a receipt forthe transaction. Alternatively, the ATM may instruct the offer server togenerate a digital coupon for the resolved consumer entity. In yetanother embodiment, the coupon is printed automatically for theconsumer, without asking the consumer if the consumer wishes to receivea coupon. In other embodiments, a link to a coupon provision mechanismfor the offer may be emailed to the consumer, texted to the consumer,posted on a social network, or included in a bank statement inassociation with the transaction.

In an embodiment, similar techniques may be applied to a variety ofother devices, including in-store kiosks, gas pumps, public interactivedisplays, airport boarding pass kiosks, ticket booths, prescriptionprinters (e.g. to provide coupons for local pharmacies), and so forth.

4.22. Retailer Data Upload

In an embodiment, retailers and other partners periodically send noncritical bulk data through a bulk data exchange interface. Data exchangeis provided through FTP and/or web services interfaces. The datasubmitted is decompressed (if necessary), processed, and loaded into thetransaction aggregation system and/or the offer distribution system. Forexample, partners may upload the following data to a bulk data module:product data such as mappings of SKU codes to UPCs and producthierarchies, consumer data such as retailer-specific consumer-records,sale transactions, offer redemption data, offer partner data,transaction type data enumerating possible transaction type codes, storedata describing each of the retailer's stores, tender data enumeratingthe possible types of tender accepted at each store's point-of-sales,and terminal data enumerating and defining receipt-processing policiesfor the retailers' possible terminals including physical terminals suchas self-checkout terminals or fuel-pumps and virtual terminals such asonline store fronts. In an embodiment, transaction data for transactionsrequiring digital receipts are sent in real-time or near real-time tothe transaction aggregation server, while transaction data for all othertransactions is batched for bulk data exchange.

4.23. Example Use of Coordinating Computer

FIG. 6 and FIG. 7 illustrate flows 600 and 700 for providing anelectronic receipt with offer information, according to an embodiment.Flows 600 and 700 are performed by a number of different components of asystem, including a consumer, merchant point of sale, coordinatingcomputer, and offer server. The consumer may correspond to, for example,consumer 535. The merchant point of sale may correspond to, for example,terminal 542. Depending upon the embodiment, the coordinating computermay correspond to retail server 540 and/or offer server 510. Thecoordinating computer may also or instead correspond to a serveroperated by yet another party for distribution of electronic receipts onbehalf of one or more retailers. The offer server may correspond, forexample, to offer server 510 or to retail server 540 operating inconjunction with offer server 510.

Flow 600 begins with block 602, at which the consumer selects one ormore items for purchase. At block 603, the consumer provides tender forthe purchase, which may include, for example, cash or credit card(s).The consumer also optionally provides a loyalty card. At block 604, themerchant point-of-sale processes the purchase and obtains the tenderprovided in block 603.

At block 606, the merchant point-of-sale optionally collects anidentifier for the loyalty card, if provided. The merchant point-of-salemay do so by, for instance, reading a magnetic strip or RFID tagembedded in the card. At block 608, the merchant point-of-sale obtainsconsumer consent to deliver the consumer's receipt and offerselectronically. If no consent is given, then at block 619 a receipt isprinted. Otherwise, at block 610 the merchant point-of-sale activates asending function.

At block 612, the sending function commences with the merchantpoint-of-sale securely sending a loyalty card number or otheridentifying number to the coordinating computer. At block 614, thecoordinating computer determines whether the number is uniquelyassociated with a known consumer identity. If so, then at block 620 apositive response is returned to the merchant point-of-sale. Otherwise,at block 616, the coordinating computer returns a negative response tothe merchant point-of-sale.

Upon receiving a negative response per block 616, the merchantpoint-of-sale may optionally request the consumer's cell phone oranother identifier, at block 618. If, at block 618, the consumerdeclines to provide a cell phone number or other identifier, flowproceeds to block 619, where the merchant point-of-sale prints areceipt. However, if the consumer provides a number or identifier, thenat block 621 the merchant point-of-sale may then securely send thenumber or identifier to the coordinating computer. The coordinatingcomputer may then repeat block 614 with the new number or identifier.

Upon receiving the positive response of block 620, then at block 612 themerchant point-of-sale generates a positive acknowledgment message, suchas a message displayed on a screen of the checkout terminal. Once block619 or 612 is completed, then at block 622 the transaction is consideredto be complete. In an embodiment, the transaction is considered completeeven if block 619 is not performed (i.e. even if a receipt is notprinted), as long as the coordinating computer located a known consumeridentity in block 614.

Flow 700 is performed upon occurrence of blocks 620/612. Flow 700 beginswith block 702, at which the merchant point-of-sale spools datacomprising SKUs or other identifiers of items purchased in the consumertransaction and sends the data along with the consumer identity (orsession data that may be used to tie the spooled data to the previouslydetermined consumer identity) to the coordinating computer. At block704, the coordinating computer generates and formats a message, based onthe SKUs. The message provides receipt data to the consumer and/or alink to a URL that may be used to obtain receipt data.

Blocks 706-708 may optionally be performed in embodiments where thecoordinating computer provides receipt data to multiple retailers,including retailers that are not subscribed to offer informationservices. At block 706, the coordinating computer determines the sourceof the spooled data. At block 708, the coordinating computer determineswhether the source point-of-sale is subscribed to offer informationservices. If not, flow proceeds to block 712. Otherwise, flow proceedsto block 710.

At block 710, the coordinating computer updates the message to includelink(s) or other data suggesting the availability of offers. In thisparticular embodiment, the link(s) simply provide the consumer withknowledge of the existence of a website on the coordinating computer atwhich the consumer may obtain offers. At block 711, the coordinatingcomputer optionally updates the message to include advertisements.Advertisements may be identified based on the merchant, consumer, oritems purchased using any suitable techniques.

At block 712, the coordinating computer renders and sends the message tothe consumer at an electronic address associated with the consumer'sidentity. At block 714, the consumer receives the message and views it.If the receipt data is not embedded directly in the message, then theconsumer may optionally at block 715 click on a link in the message todisplay the receipt data. In response, at block 717 the coordinatingcomputer optionally interacts with the consumer to obtain consumercredentials, and then displays the receipt data upon the consumerproviding the credentials.

At block 716, the consumer selects a particular link in the message orreceipt data. In response, at block 718 the coordinating computerdisplays information about relevant offer(s) associated with the link,including call-out(s) for selecting the relevant offer(s). In responseto this display, the consumer selects a particular call-out. Inresponse, at block 722 the coordinating computer receives and redirectsthe selection to the website of the offer distributor. At block 724, theoffer distributor displays offer(s) or other advertisement informationrelated to the call-out. At block 726, the offer distributorelectronically interacts with the consumer to send, display, save,and/or print coupon(s) for the relevant offer(s).

Flows 600 and 700 illustrate a specific example implementation of thetechniques already described herein. Other embodiments may includeadditional or fewer steps performed by potentially different entities inpotentially different orders.

4.24. Example Use of Consumer Identifier for Both Redemption AndDistribution of Offers

In an embodiment, offer information is provided electronically inassociation with receipts for transactions at physical stores and/oronline stores. A retailer causes performance of a transaction in whichone or more items are purchased. An interface configured to accept inputindicating a consumer identifier associated with the transaction, suchas an email address or other consumer identifier as described inprevious sections, is provided. When input has been received via theinterface, it is determined whether the identifier is associated with aknown consumer identity. If the consumer identifier is associated with aknown identity, digital coupons associated with that identity areapplied against the transaction. An electronic receipt is furtherprovided for the transaction via, for instance, the provided emailaddress or a web-based application in which a session has beenestablished in connection with the identity. Otherwise, a printedreceipt may be provided.

FIG. 10 illustrates a retailer-centric flow 1000 for using a singleconsumer identifier to locate digital coupons for redemption in atransaction, and to identify an electronic address at which to provide adigital receipt, according to an embodiment.

Block 1010 comprises providing an interface configured to accept inputindicating consumer identifiers associated with transactions. Theinterface may be provided, for example, in the same manner as theinterface of block 330. As with the interface of block 330, theinterface need not be furnished by the retailer, as long as theinterface is made available for use in transactions with the retailer'sconsumers.

Block 1020 comprises receiving first input via the interface indicatinga first consumer identifier associated with a first transaction. In thecontext of this disclosure, “first” is merely a label for purposes ofclarity to distinguish one thing from another, and is not intended toimply something that is first in order or first to occur. In anembodiment, the first input specifies an email address or other suitableconsumer identifier. For example, prior to the completion of the firsttransaction, a sales clerk may prompt the first consumer to input anemail address via a keypad interface, or the sales clerk may input theemail address as the consumer provides the address orally. As anotherexample, the email address may be transferred electronically via awireless signal, such as in contact information embedded in a NFCtransmission. As another example, the email address may be determined atthe point of sale by analyzing images or sounds recorded by a sensor.For example, the first consumer may present a card or mobile devicedisplay screen showing a QR code, bar code, other symbolicrepresentation, or textual representation of the email address and animage of the code or representation may be captured by a scanninginterface. Or, the consumer may generate an audio signal that may becaptured by a microphone interface. The terminal or an interfacecomponent may then analyze the captured information through varioustechniques, such as pattern recognition, signal processing, and/oroptical character recognition, to decode and/or recognize the emailaddress. Other types of consumer identifiers and interfaces may also beutilized, as described elsewhere in this disclosure.

Block 1025 comprises receiving input specifying a first set of one ormore items for purchase in the first transaction and, optionally, one ormore payment mechanisms. The input may be received in the same manner asthe input of block 310. Block 1025 may occur at any time relative toblock 1020.

At block 1030, at least partially responsive to receiving the firstinput via the interface, the flow determines whether the first consumeridentifier is associated with a known consumer identity. For example,upon receiving the first consumer identifier, the terminal may queryanother computer such as a retail server or offer server using the firstconsumer identifier. The computer may respond with an indication thatthe first consumer identifier corresponds to a known consumer identity.As another example, the retail server may query another computer usingthe first consumer identifier.

In either case, the query may take a number of forms. For example, thequery may simply request that the other computer respond with a positiveor negative indication. Or, the query may request that the othercomputer respond with an account identifier for the known consumeridentity. In an embodiment, the query requests information such as alist of digital coupons or payment mechanisms corresponding to the firstconsumer identifier. The other computer may be configured to respondwith the requested information if the first consumer identifiercorresponds to the known consumer identity, and to otherwise respondwith an indication that the first consumer identifier does notcorrespond to any known consumer identity. In an embodiment, theterminal or retail server may itself comprise a database or cache ofconsumer identifiers and known consumer identities, which may then besearched using the first consumer identifier.

Block 1040 comprises identifying digital coupons, including a first setof one or more digital coupons, associated with the first consumeridentifier. In an embodiment, the first set of one or more digitalcoupons are digital coupons that were generated in response to theconsumer previously selecting offers to save to an account that ismapped to the first consumer identifier. However, in other embodiments,the first set of one or more digital coupons is a set of digital couponsthat has become associated with the first consumer identifier by othermechanisms, such as digital coupons that were generated automaticallyfor the consumer in response to previous transactions orretailer-initiated events. The availability of digital coupons for thefirst consumer may be identified by analyzing coupon availability datamapped to the first consumer identifier or an account associated withthe first consumer identifier. For example, a terminal may query anoffer server or retail server for a list of digital coupons that havebeen saved to an account associated with the first consumer identifier.Various techniques for identifying digital coupons associated with anaccount are described elsewhere in this disclosure, as well as in U.S.application Ser. No. 12/878,231, already incorporated by reference.

In an embodiment, block 1040 and block 1030 are the same, in that theidentification of one or more digital coupons associated with the firstconsumer identifier implies that the first consumer identifier isassociated with a known consumer identity. In other embodiments, block1040 may be performed before or after block 1030.

Block 1050 is performed at least partially responsive to receiving thefirst input and determining that the first consumer identifier isassociated with a known consumer identity. Block 1050 comprises block1052 and block 1054. Block 1052 comprises causing performance of thefirst transaction, in which a first set of one or more items arepurchased, at least in part, using the first set of one or more of thedigital coupons associated with the particular consumer identifier.

In an embodiment, the terms of each of the digital coupons are comparedto various properties of the first set of one or more items in thetransaction, and it is determined that the first set of one or morecoupons are eligible for use in the transaction. In an embodiment, theeligibility of the first set of one or more digital coupons may havebeen determined in the identification process of block 1040. Forexample, when querying a retail server or offer server, a terminal mayinclude transaction details such as a description of the first set ofone or more items. When returning the digital coupons in block 1040, anoffer server or retail server may limit the returned digital coupons toonly those that are eligible for use in the transaction, based on thesetransaction details.

Any suitable technique may be used for calculating a total for the firsttransaction and securing payment, including, without limitation, thosedescribed in Section 4 and elsewhere in this disclosure.

Block 1054 comprises causing communicating an electronic receipt for thefirst transaction via at least one of an email message or a web-basedapplication. The email address for the email message, or the electronicaddress through which web-based application retrieves the electronicreceipt, is determined based on the first consumer identifier. Forexample, if necessary, various lookup operations may be utilized tolocate an email address associated with the first consumer identifier,or an electronic address and corresponding database record inassociation with which to save the electronic receipt for laterretrieval via a web-based application. Block 1054 may be performed usinga variety of techniques described herein, including, without limitation,those described with respect to block 370 of FIG. 3 or block 702 of FIG.7.

Block 1060 comprises receiving input specifying a second set of one ormore items for purchase in a second transaction and, optionally, one ormore payment mechanisms. “Second” merely refers to another thing that isdifferent from the first, and does not imply a particular ordinalposition or occurrence. The input may be received in the same manner asthe input of block 310. Block 1060 may occur at any time relative toblocks 1020-1050.

At block 1070, the flow proceeds to complete the second transactionwithout having received any consumer identifier associated with anyknown consumer identity via the interface(s) of block 1010. For example,the terminal may be configured to proceed with the transaction without aconsumer identifier if no input has been received after a predeterminedtime, or if the consumer or cashier declines to provide a consumeridentifier. Such a determination may also occur in response toconditions such as those in block 616, 618, where a provided consumeridentifier is determined not to be associated with a known consumeridentity. In an embodiment, the consumer may be given an opportunity toestablish a known consumer identity; however performance of block 1070would occur if the consumer declined to do so.

Block 1080 is performed at least partially responsive to not receiving,via the interface, in association with the second transaction, any inputthat indicates any consumer identifier associated with any knownconsumer identity. Block 1080 comprises block 1082, 1084. Block 1082comprises causing performing the second transaction, in which a secondset of one or more items are purchased. The second transaction isperformed in a manner similar to that of the first transaction. However,the second transaction may be performed with or without applying digitalor printed coupons. In an embodiment, the second transaction isperformed without applying any digital coupons that originated from thesame distributor as the digital coupons of block 1040, since the secondconsumer cannot be resolved to a known consumer identity at thedistributor.

Block 1084 comprises causing communicating a printed receipt for thesecond transaction. Block 1084 may performed in a manner similar toblock 380 of FIG. 3.

Flow 1000 is one example of the variety of possible techniques forconducting a transaction in which an electronic receipt is communicated.Other embodiments may include additional or fewer elements in varyingorders. For example, while flow 1000 depicts an embodiment in which thefirst consumer that provides the first consumer identifier is alwaysprovided with an electronic receipt instead of a printed receipt, othertechniques may allow the first consumer to select a printed receiptinstead of or in addition to an electronic receipt. Similarly, in yetother embodiments, no eligible digital coupons may be returned in block1040. However, the first consumer may obtain an electronic receiptwithout any digital coupons being applied to the first transaction.

Although flow 1000 is from a retailer-centric perspective, it is notnecessary for all of flow 1000 to occur at computing devices operated bythe retailer. However, in an embodiment, the entire flow 1000 isperformed collectively by a terminal and/or retail server, based oncommunications with an offer server or other computer associated with aservice provider.

FIG. 11 illustrates an offer distributor-centric flow 1100 for using asingle consumer identifier to locate digital coupons for redemption in atransaction, and to identify an electronic address at which to provide adigital receipt, according to an embodiment.

Block 1110 comprises receiving, from a retailer, account identifyinginformation for a consumer. The account identifying information may beany type of consumer identifier, including without limitation an emailaddress. The account identifying information may be received in anysuitable manner, including the manners described with respect to block410 and elsewhere in this disclosure. Block 1120 comprises identifyingan account associated with the account identifying information, such asdescribed in block 420.

Block 1130 comprises identifying one or more digital coupons, which mayor may not be associated with the account. The one or more digitalcoupons may be identified, for instance, by querying a data repositoryfor digital coupon identifiers associated with the account. Block 1140comprises providing to the retailer coupon availability data indicatingthat the one or more digital coupons are associated with the accountidentifying information. The provision of coupon availability data isdescribed elsewhere in this disclosure.

Block 1150 comprises receiving, from the retailer, transactioninformation for a transaction between the retailer and the consumer. Thetransaction information may comprise transaction data such as describedin block 410 and elsewhere in this disclosure, including the accountidentifying information for the consumer.

In an embodiment, the transaction information includes offer redemptiondata indicating that the one or more digital coupons were applied to thetransaction. Optionally, at block 1160, an offer server may remove anyredeemed digital coupons from the consumer's account based on the offerredemption data. The offer server may further notify other retailers whomay have cached copies of previous coupon availability data for theconsumer that the redeemed digital coupons are no longer available forthe consumer. In other embodiments, updating of coupon availability datais instead achieved through various asynchronous backend processes.

Block 1170 comprises generating an electronic receipt based on thetransaction information, as described in block 440. The electronicreceipt may optionally include offer information, as described elsewherein this disclosure, by which the consumer may add new digital coupons tothe consumer's account. Block 1180 comprises providing the electronicreceipt via an electronic address associated with the account, asdescribed in block 450. In an embodiment where the account identifyinginformation is an email address, the electronic receipt, or anotification of the electronic address via which the electronic receiptis available, is delivered to the email address.

Flow 1100 is one example of the variety of possible techniques forproviding digital offer information and an electronic receipt. Otherembodiments may include additional or fewer elements in varying orders.For example, in an embodiment, blocks 1130-1140 are performedasynchronously to at least blocks 1110, 1150, 1170. Rather than wait fora retailer to request coupon availability data for a consumer, the offerserver proactively identifies digital coupons associated with each ofmultiple consumer accounts and pushes the coupon availability data tothe retailer in, for example, periodic batches. The coupon availabilitydata is then cached by the retailer. In such an embodiment, block 1110is an element of block 1150, in that the retailer only needs tocommunicate with the offer server once, upon completion of thetransaction.

In an embodiment, some of the transaction information of block 1150,including at least the list of item(s) involved in the transaction, isreceived before the transaction is conducted. The coupon availabilitydata is compared to the list of items and filtered so as to provide theretailer with only a set of those digital coupons that are eligible foruse in the transaction. The remainder of the transaction information ofblock 1150 is transmitted, or the entire transaction information isretransmitted, upon completion of the transaction. Furthermore, becauseeach provided coupon is known to be eligible for the transaction, in anembodiment block 1160 may be performed even without coupon redemptiondata being included in the transaction information.

4.25. Other

In an embodiment, rather than requiring a retailer to deploy its ownsolution for sending data to a transaction aggregation system, an offerdistributer provides retailers with a local service that synchronizeswith the offer distributor's central server on an ongoing basis.

In an embodiment, a consumer can access various platform featuresdescribed herein (digital receipts, coupons, lists, etc.) throughvarious means based on retail entity preferences. Three primaryexperiences based on retailer entity preference include: White LabelUX—Interface features are hosted by the offer distribution system, butembedded in a transparent fashion in to a partner's websites (eitherthrough proxy or IFrame); Partners Website—Retail partners build theirown interface for platform features using APIs provided by the offerdistributor; Distributor UX—Distributor-branded interface where aconsumer directly logs in to and interacts with offer servers, receiptservers, and so forth.

In an embodiment, each of the above interfaces is built to supportmultiple resolutions and devices. For white labeling purposes, theinterface supports CSS-based templates to drive the look and feel.Partners can easily apply their style sets. For white label and thirdparty entity websites, user authentication is handled by partners.Requests are sent to the offer distribution system after authentication.Retailers who opt in for White Label option use a dedicated URL withinthe retailer domain (e.g., receipts.retailer.com) name for receiptfeatures. That URL is pointed to a distributor-based URL using CNAMEcapabilities. This allows the receipt server to access any cookiesagainst that URL. The retailer, after authenticating the user, creates auser cookie against that URL. This cookie is used by the distributor toprovide customized experience for that user.

In an embodiment, various pricing constructs may be utilized fortargeted offers. In an embodiment, a variable targeting fee is added toa standard unit rate. For example, an offer provider may bid $X,000 totarget upper-income males in Georgia, plus 14 cents per activation. Inan embodiment, only a variable unit rate is used. For example, an offerprovider may bid X cents per activation to target upper-income males inGeorgia.

5.0. Example Data Architecture

Various embodiments described herein reference “data stores.” A “datastore” is an collection of structured data, including databases, filesystems, and so forth.

While in some embodiments, each of the data stores described herein arephysically separated from each other data store, in other embodimentsthe separation between some or all of the data stores described hereinis a logical abstraction. For instance, offer data 1385 and offeractivation data 1388 may be occupy overlapping databases or even tablesand records within those databases. Various data architectures aredescribed in subsequent sections.

5.1. Data Sources

Example data sources include transactional data, customer preferences,product taxonomy, and product attributes. From transaction files thepurchase history of every user is also identified and recorded. Couponspecific metrics should also be extracted to generate a customeranalytic record for customer segmentation, in order to generate morepersonalized recommendations. Examples of useful features are the timesof day at which a customer activates coupons, the time of day at whichhe/she visits the retailers' stores and redeems coupons, the days ofweek coupons are redeemed, the average number of trips to the retailers,the number of coupons redeemed the product categories purchased, thepreferred payment method and so on.

Apart from the above, retailer-related data sources, the followingdistributor-related data sources may also be useful. A coupon to productmapping, that relates every coupon to the product(s) that it is relatedto, is useful when generating recommendations. A coupon activations filethat registers the time a specific customer activated a specific couponallows identifying patterns in coupon activations, to extract thepreferences of customers, and to estimate important KPIs related tocoupon activations. This file can contain both automatically activatedand customer activated coupons so as to estimate the related KPIs forboth. Coupon redemption information, that records who has redeem acoupon, what coupon was that, to which product and offer is thisassociated, at which retailer was this coupon redeemed what time of day,can be extracted through the retailer transactional data if properlyrecorded. Coupon impression records enable an assessment the effect ofcoupons on their revenues. These impressions may optionally have a timedimension, that is the exact time an impression was recorded, and also acustomer dimension, that is the identity of the individual who watched aspecific coupon.

Also, in order to be able to combine data from various sources, thefollowing sources of information may be useful. A customer mappingincludes, for each specific customer, one or more customer identifiersand/or loyal card numbers that he or she have in the records of everyassociated retailer. A product mapping table connects the productidentifiers (e.g. SKUs) of every retailer to those of distributor and tothe corresponding UPC. A global product taxonomy is connected thetaxonomy of every associated retailer and may be applied to deliverassociation analysis results at various levels if requested. These andvarious other data sources, such as product descriptions, store andterminal location data, and so forth may be used by the receipt serverto translate terse transaction logs into detailed, human-readablereceipts.

Rating files, when available can be processed to generate usefulrecommendations as well. Advanced algorithms generate ratings for allproducts for every user, based on the ratings that users have alreadyprovided. Then, products that are estimated to be rated high from a usercan be recommended to this user.

Product taxonomy is useful because it provides the various levels of theproduct hierarchy. Specifically, for retailers with a large productrange with a “long tailed” purchasing pattern or where the user to itemassociation matrix is too sparse, product taxonomy can be used to applyassociation analysis at various levels of the product hierarchy and thusenrich the recommended items list. Notice that this method can be alsoused to tackle the “cold start” problem that is the situation where weneed to generate recommendations for items that have not been sold yet.

Product attributes are useful to identify similarities among productswithin a specific product category. This type of information cancontribute toward the development of algorithms that assess thesimilarity of products within the same category. Product attributesalong with ratings (if available) or sales can be used to performattribute weight analysis and estimate the importance of every attributeto the revenue of the retailer. This is a tedious process though thatrequires a significant amount of work for the attribution of products.Product descriptions are used, when product attributes are unavailable,in order to identify the similarity of products, by applying appropriatetext similarity algorithms.

Customer demographics are, along with other data like user preferences,used in identifying the similarity between customers, a significantcomponent of several collaborative filtering algorithms. Customerdemographics can be used also to post process the derivedrecommendation, by applying for instance gender, age and marital statusinformation.

Store characteristics are significant in order to account for thelocation where a purchase is placed in the generated recommendations andfor the store size and specific characteristics.

The same input data can also be used to generate the customer analyticrecord (CAR) that provides all the information related to the behaviorand the characteristics of a customer. The CAR includes customer relatedKPIs like the number of purchases by a customer, his/her average basketsize, the time (the days of week, time of day) and locations at whichhis/her purchases were made, the average number of trips to the store,the product categories purchased, the preferred payment method and soon. This CAR can be used later on to perform micro- ormacro-segmentation and to assist the personalization of recommendations.

5.2. Transaction Logs/Tables

In an embodiment, transaction data is stored as a table of transactionlogs. A transaction log is a unique record of the information capturedat a store during a transaction. Besides recording items sold,promotions, and method of tender, transaction logs may include returnsof goods, ‘no sale’ actions such as cash in/out, and associate clockingin/out. Generically known as Tlog, the actual content will vary betweenretailers. Common formats include IBM's GSA Tlog and Nation RetailFederations ARTS standard POSLog (XML).

For example, in an embodiment, a transaction log may include some or allof the following fields: transaction identifier, transaction duration,transaction date/time, master customer identifier, store identifier,retailer customer identifier, tender type(s), tender amount(s), registeridentifier, cashier name, transaction type, line item count, lanenumber, total purchase amount, percent savings, total amount saved, taxamount(s), currency code, currency conversion rate, store detail(s),discount amount, return by date, thank you message, loyalty pointsearned, current loyalty points, email address or mobile phone number fordigital receipt, receipt delivery preference, payment identifier(s) suchas credit card numbers and other PANs, and transaction line items. Thetransaction line items may, in turn, be stored in a separate tablecomprising fields such as transaction identifier, UPC, SKU, EAN/IAN,line item type, quantity, weight, unit price, item discount, associatedoffer identifier, item description, and so forth. In an embodiment,tender information for each type of payment tendered in a transactionmay also be stored in a separate table, including fields such as tendernumber, tender identifier, tender type, tender amount, customer name,payment card token, method of entry (swiped, keyed, etc.), authorizationcode, tender amount, currency identifier, balance amount, cashback,voucher number, coupon number, and so forth.

In some embodiments, additional tables may exist, for example, to recordinformation about applied coupons, aggregate various sales data,maintain original transaction logs from retailers in non-canonical form,and so forth.

5.3. Offer Tables

In an embodiment, example offer data may include a campaign table at thehighest level, with a one-to-many relationship with offer records inoffer table. The offer table contains an entry for each offer, eachlinked to various tables to provide further definition. Each entry mayinclude, without limitation, one or more product identifiers, an offercode, a start date, an end date, a unit cost, an offer status, offerdescription(s), an offer type code, a campaign code, a promotion code,an offer sub type code, an offer intent, an offer family code, an offerrestriction code, an offer geographic area, a clearinghouse,distribution limit(s), and so forth. The linked tables may include anoffer type table to distinguish the different types of offer, such asDisplay ad, CPC, CC offer, E-Circ, and so forth. The offer sub typetable provides descriptions for the offer type and sub type, such asprint, digital, and so forth. An offer property table providesattributes specific to the type of offer. An offer channel tableidentifies the various channels by which the user accesses the offers.An offer delivery table identifies the various ways to deliver theoffers, such as QR codes, SMS, e-mails, video, Facebook, Twitter, and soforth.

Offer data may further include offer activation table(s) and offerredemption table(s) mapping consumer entities to offers they haveactivated or redeemed, along with timestamps for theactivations/redemptions.

5.4. Consumer Tables

In an embodiment, consumer data may include a master customer accounttable comprising a record for each customer entity/identity. Theconsumer data may further include third party entity customer accountdetail table(s), in which each retailer's raw customer records arestored along with timestamps reflecting when they are created ormodified. Each raw record indicates a set of credentials that werepresented during one or more transactions. The raw records may becorrelated together using correlation techniques as described herein toform an entity customer account master table in which each entity has acustomer record, aggregated and/or consolidated from the raw records,for each of its customers. Each of the above tables may include fieldssuch as, without limitations, a master customer identifier to which therecord has been correlated, an entity identifier (for the entitytables), first name, last name, middle name or initial, one or moreloyalty identifiers, one or more mobile phone numbers, one or more emailaddresses, one or more PAN numbers, one or more addresses, a householdidentifier, and so forth.

In an embodiment, customer data may further include one or morehousehold tables, comprising household records in which data frommultiple customer entities belonging to the same household areconsolidated. For example, retailer data may link multiple loyalty cardsto a same household. Or, customers with a same credit card, sameaddress, but different name may be linked to a same household record.Or, customers with a same address may be linked to a same household.

In an embodiment, the targeting techniques described herein may targetrecords from any one of the above described tables. In an embodiment,consumer data may further include detail tables or demographics table(s)that are linked to any of the above, such as tables with a consumer'sage, location, gender, digital receipt and other contact preferences,and so forth.

5.5. Product Tables

In an embodiment, item data comprises a master product table, comprisingrecords for each unique item. The master product table may comprisefields such as, without limitation, product identifier, UPC, department,category, subcategory, segment, and line. Separate tables may also existfor some or all retailers, including similar fields and/or SKU numbers.Additional tables may exist for information such as item descriptions,attributes, ratings, historical prices, product images, and/orinventory.

5.6. Other Tables

In an embodiment, a variety of other tables may also exist, includingwithout limitation a retailer table, stores table, consumer actiontracking table(s), a consumer offer recommendation table, various lookuptables such as an offer by geography table, language tables, and soforth.

6.0. Example System Architectures

FIG. 5 is a block diagram illustrating an example system 500 in whichthe techniques described herein may be practiced, according to anembodiment. System 500 comprises an offer server 510 operated by anoffer distributor 515, a client 520 operated by a consumer 535, and aretail server 540 and terminal 542 operated by a retailer 545.

6.1. Retailer

Retailer 545 is any entity that conducts transactions in whichconsumers, such as consumer 535, redeem offers via the couponsdistributed by offer server 510. Retailer 545 may be a single store, ora corporation that operates a group of stores. Consumer 535 may engagein transactions with retailer 545 at, for example, a brick-and-mortarstore operated by retailer 545.

Consumer 535 may also engage in transactions with retailer 545 via awebsite operated by or on behalf of retailer 545.

A transaction as used herein refers to the act of a retailer such asretailer 545 obtaining payment for the provision of, or the formation ofa contract to provide, certain product(s) and/or service(s). Obtainingpayment may include receiving a physical or electronic transfer ofpayment, debiting an account, obtaining a hold on funds, securing fundsin escrow, obtaining points or other non-monetary value from an accountor escrow or other transfer, or obtaining any form of value from anelectronic wallet. A transaction is initiated by a consumer's selectionof products or services to purchase. Products and purchases arecollectively referred to herein as “items.” The consumer may signal thisselection by initiating a checkout process by, for example, bringingselected products to terminal 542. The checkout process may involve theconsumer providing retailer 545 with any information necessary tocomplete the transaction, such as account or wallet information, billingparticulars and/or delivery instructions.

In an embodiment, retailer 545 is capable of distributing and acceptingdigital coupons from a provider 595 even though retailer 545 is aseparate and distinct entity from the provider 595 and offer distributor515. However, in other embodiments, retailer 545 may be the same as oneor both of provider 595 and offer distributor 515.

6.2. Terminal

Terminal 542 is a data processing system operated by a retailer forconducting in-store (i.e. “point of sale” or “brick and mortar”)transactions. Terminal 542 may be, for example, a register operated by asales clerk or a “self-checkout” stand operated by consumer 535.Terminal 542 comprises input mechanisms by which a clerk and/or theconsumer may input information for conducting a transaction, includingitem identifiers and item quantities. The input mechanisms may include,without limitation, keyboards, pointing devices, touch screens, bar-codereaders, cameras, scales, and radio frequency identification (“RFID”)readers. Terminal 542 is coupled to a database of item identifiers, inwhich each item identifier is mapped to one or more prices. Terminal 542may further comprise or be coupled to one or more payment mechanisms,such as a cash register, check verification system, or credit cardreader.

Terminal 542 is coupled to a printing component 549 by which terminal542 may print receipts of transaction data for transactions, oncecompleted. In an embodiment, a printed receipt may include one or morecoupons printed therein. Terminal 542 also or instead includes executionlogic for causing electronic transaction receipts to be provided toconsumer 535 via an electronic address, such as an email address, textmessaging address, social messaging address, or URL. For example,terminal 542 may utilize a consumer identifier 532 of consumer 535 tolocate account information that includes the electronic address. Such anaccount may be stored at, for example, retail server 540 or offer sever510. Or, consumer 535 may provide the electronic address directly toterminal 542. Terminal 542 may then send the receipt to the electronicaddress, or provide the transaction details to a server, such as retailserver 540 or offer server 510, that is configured to send the receiptor otherwise make the receipt available to consumer 532 at theelectronic address. Terminal 542 may cause the digital transactionreceipt to include offer information, such as general links to an offerdistribution website or more specific links from which consumer 535 mayobtain coupons for specific offer(s) displayed in association with theelectronic receipt.

As used herein, “causing” performance of an action may be interpreted assending, transmitting, or saving data that, when processed by an entityor any combination of entities at least partially triggers functionalityat the processing entity or combination of entities that either performsthe act or causes performance of the act.

Regardless of the type of receipt generated for transactions at terminal542, the one or more coupons or offers associated with the receipt maybe selected using a variety of techniques, including random selection,selection based on items in the transaction, selection based on the timeor date of the transaction, and/or selection based on store location atwhich the transaction occurs. In an embodiment, terminal 542 requeststhat another server, such as a retail server 540 or offer server 510,identify the one or more offers based upon transaction informationfurnished by terminal 542.

In an embodiment, retailer 545 allows consumer 535 to redeem an offer bypresenting a printed or digital coupon at terminal 542 while engaging inan applicable transaction. In an embodiment, retailer 545 allowsconsumer 535 to redeem an offer by presenting an identifier whileengaging in a transaction. Terminal 542 uses the identifier to locateapplicable coupon(s) that have been saved to the consumer's account. Inan embodiment, terminal 542 communicates with offer server 510 to locateapplicable coupon(s) that have been saved to the consumer's account. Inan embodiment, terminal 542 instead relies upon offer server 510 to pushcoupon availability data for various account identifiers to retailserver 540. For example, offer server 510 may periodically provideretail server 540 with a table of account identifiers and newlyassociated or disassociated digital coupon identifiers. Retail server540 may then update a local database based on the coupon availabilitydata. Suitable techniques are described, for instance, in U.S.application Ser. No. 12/878,231, filed Sep. 9, 2010, the entire contentsof which are hereby incorporated by reference for all purposes as iffully set forth herein.

Terminal 542 periodically, or in response to a transaction, reportscoupon usage data to offer server 510. Coupon usage data indicates theredemption of one or more offers, along with unique identifiersassociated with the redemptions, so that coupons may be removed from theredeeming consumer's account(s). In an embodiment, terminal 542 isfurther configured to periodically send transaction data to offer server510. The data may include one or more of sales price(s), transactiondate(s) and time(s), and identifiers of product(s) or service(s)included in each transaction. The periodic requests may occur hourly,daily, or upon a certain number of transactions, for example.

6.3. Retail Server

In an embodiment, terminal 542 is coupled to retail server 540 via anetwork, such as a company intranet. In an embodiment, a server mayrefer to one or more components executing on one or more computers ordevices that interact with counterpart client applications executing onother computers or devices. Thus, retail server 540 may refer to one ormore server components executed at one or more computing devices underthe control of retailer 545. Retail server 540 may coordinatetransactions amongst a plurality of terminals 542. Retail server 540 isan optional component of system 500. However, in an embodiment, some orall of the communications to and from terminal 542 pass through retailserver 540. In various embodiments, any number of functions describedherein as being performed by a terminal such as terminal 542 may in factbe performed, at least in part, by retail server 540. Likewise, anynumber of functions described herein as being performed by a retailserver such as retail server 540 may in fact be performed, at least inpart, by terminal 542. In an embodiment, terminal 542 is a “thinclient,” and all functions other than input and output are shifted toretail server 540.

In an embodiment, retailer 545 host a website via retail server 540, atwhich consumer 535 may access electronic receipts and associated offerinformation via one or more web addresses. The website may be providedas a “digital locker” of receipts for transactions in which any of theconsumer's identifiers have been provided. For example, a consumer 535may login to a website hosted by retail server 540. Once logged in,consumer 535 may access a list of recent receipts by visiting a specificweb address. The list of receipts may further contain links to webaddresses hosted by the retail server 540 or an offer server 510 atwhich the consumer may obtain coupons for one or more offers. The offersmay be non-targeted and/or targeted. In an embodiment, the one or moreoffers may be selected specifically for the consumer in association withthe receipt. In an embodiment, such a website may also or instead behosted by another entity such as offer server 510. The website may beaccessed in response to a notification of the availability of a digitalreceipt, such as an email, text message, or operating system alert. Thewebsite may also or instead be accessed proactively by the consumerwithout having received a notification.

In an embodiment, retail server 540, offer server 510, or any otherserver described herein may include or be coupled to a variety ofdifferent components for implementing the techniques described herein,including database server(s), email or text messaging server componentssuch as an SMTP server component, and web/application server componentsfor responding to requests addressed to various addresses and ports withweb pages and/or other data. Web/application server components may relyupon any suitable protocol or application language, including HTTP,HTTPS, SSL, HTML, XML, PHP, Java, JavaScript, SOAP, and so forth.

In an embodiment, retail server 540 comprises executable logic similarto that of the offer server for generating coupons. For example, offerdistributor 515 may provide one or more libraries of offer distributioncode for retailer 545 to utilize in retail server 540. As a condition ofexecuting such logic, retail server 540 is configured to communicateperiodically via an application program interface with offer server 510,via which offer server 510 provides retail server 540 with the coupondata necessary for retail server 540 to generate coupons. For example,offer server 510 may provide retail server 540 with terms of offers forwhich consumers of retail server 540 are currently eligible,instructions for generating a unique coupon identifier for each offer,and/or applicable distribution limits and parameters. Retail server 540is further configured to report distributions to offer server 510 on aperiodic basis.

In an embodiment, retail server 540 and terminal 542 are special-purposecomputers configured with logic that can perform the operationsdescribed herein during operation. In an embodiment, client 520 is ageneral-purpose computer that comprises one or more processors, andmemory, mass storage device, or other non-transitory computer-readablestorage media storing instructions which, when loaded and executed,cause the one or more processors to perform the operations that arefurther described herein.

6.4. Offer Provider/Distributor

In an embodiment, offer distributor 515 is any entity capable ofdistributing offers on behalf of an offer provider 595, such as amanufacturer, retailer, or advertiser. For the purposes of thisdisclosure, distributing an offer may refer to either or both ofgenerating a coupon and saving an offer to a consumer account inassociation with one or more account identifiers. In this context,generating a coupon may include printing a coupon or creating andstoring digital data representing a digital coupon.

An offer provider 595 may contract with offer distributor 515 todistribute offers as part of an offer campaign. The offer provider 595supplies offer distributor 515 with offer distribution data describingthe offer(s), as well as parameters for each offer campaign, such as atarget number of offers to distribute in aggregate, how many offers maybe supplied to each individual end user or device, regional distributionlimits, a clearinghouse to use for the campaign, and/or start and enddates for distribution. In an embodiment, offer distributor 515 makesoffers available on behalf of multiple offer providers 595.

Offer providers 595 may transmit offer distribution data to offerdistributor 515 electronically via a network connecting offer provider595 to offer server 510. For example, offer server 510 may feature a webapplication, file sharing, or database access component by whichproviders 595 may upload offer distribution data directly to offerserver 510 or offer data store 512. Additionally or alternatively, offerproviders 595 may transmit offer distribution data to offer distributor515 by any other suitable means, including orally over a telephone orvia an email.

6.5. Offer Server

Offer server 510 is operated by an offer distributor 515 for, amongother purposes, making offers available to consumers such as consumer535. Offer server 510 may be one or more server applications, executingat one or more computing devices operated by offer distributor 515. Inan embodiment, offer server 510 is a special-purpose computer configuredwith logic that can perform the operations described herein duringoperation. In an embodiment, offer server 510 is a general-purposecomputer that comprises one or more processors, and memory, mass storagedevice, or other non-transitory computer-readable storage media storinginstructions which, when loaded and executed, cause the one or moreprocessors to perform the operations that are further described herein.

Offer server 510 makes offers available to consumers, such as consumer535, on behalf of one or more offer providers 595. In an embodiment,offer server 510 distributes printable coupons for various offersdirectly to consumer 535 via client 520, which is in turn coupled to aprinter 529 at which the printable coupons may be printed. Offer server510 also makes digital coupons for various offers available to theconsumer 535 by means of saving information identifying digital couponsrequested by consumer 535 to one or more accounts associated withconsumer 535. The consumer 535 may then provide a retailer 545 with anidentifier for the account, such as a store loyalty account number orconsumer name, so that retailer 545 may retrieve any applicable digitalcoupons during a transaction. Offer server 510 also makes digitalcoupons available to the consumer 535 indirectly, via retailer 545. Forexample, in response to a retail server 540, operated by retailer 545,requesting a digital coupon on behalf of consumer 535, offer server 510may generate a digital coupon and provide retail server 540 withinformation about the generated coupon. In other embodiments, offerserver 510 need not necessarily be capable of distributing offers viaany particular technique described herein.

Offer server 510 receives and responds to offer-related requests fromclient 520 and retail server 545 over one or more networks, such as theInternet. Offer server 510 retrieves offer data from data store 512 torespond to various requests from client 520 and retail server 545. Forexample, client 520 may request offer server 510 to provide a listing ofavailable offers, search for an offer based on keywords, save aspecified digital coupon to a consumer account for consumer 535, orprint a specified coupon. In response, offer server 510 may retrieve anyrelevant offer data from data store 512, process the offer data asappropriate, and, based on that processing, formulate a response to theclient. In an embodiment, offer server 510 hosts one or more web sitesfor such interactions with client 520. The offer server 510 sends webpages to a web browser executing at client 520 with instructions forcausing the web browser to display various graphical interfaces relatedto viewing, selecting, printing, and/or saving coupons. In anembodiment, offer server 520 features an application programminginterface (“API”) by which a dedicated application at client 520, havingits own graphical interfaces, may communicate with offer server 520.

As another example, offer server 510 may provide retail server 540 withinformation about offer terms, digital coupon availability, and consumeraccounts, via a suitable API. Retail server 540 may, in turn, provideoffer server 510 with data indicating consumer coupon redemptions and/ortransaction data.

Offer server 510 may be configured to control coupon distribution in anumber of ways. For example, offer server 510 may be configured to denya client permission to print the coupon, in accordance withdevice-based, client-based, or aggregate distribution limits As anotherexample, offer server 510 may be configured to deny a request togenerate a coupon for a consumer if an equivalent coupon has alreadybeen generated from client 520. Offer server 510 may further beconfigured to deny a client permission to print a coupon based ongeographic information associated with the client.

Offer server 510 may use distribution logs for sending distributionreports to offer providers 595. The form of a distribution report mayvary, and may include at least data indicating either a total number ofoffers that have been distributed for a particular campaign or a totalnumber of offers that have been distributed for the particular campaignsince the last distribution report. Distribution reports may be sent atvarying frequencies, and in some embodiments a report may be sent eachtime a particular coupon is printed. Distribution reports may furtherinclude information harvested from device data made known to offerserver, such as geographic information or client types of the devices towhich offers have been distributed.

FIG. 8 illustrates a computer configured to implement certainembodiments. In particular, FIG. 8 illustrates an example of offerserver 510 implemented as a special-purpose computer, denoted offerserver computer 810, and comprising one or more central processing units802, operating system or virtualization logic 804, point of saleinterface logic 812, account identifying logic 814, offer selectionlogic 816, receipt forming logic 818, SMTP daemon logic 820, web serverlogic 822, offer availability logic 826, and offer provider interfacelogic 824.

In an embodiment, the one or more central processing units 802 compriseCPUs, processor cores, or other instruction processing elements that arecapable of interacting with input-output resources such as data store512. In an embodiment, operating system or virtualization logic 804comprises any of a server computer operating system, virtualizationsystem such as a hypervisor, or a hardware-based hypervisor such asIntel Xen coupled to a compatible operating system. The point of saleinterface logic 812 is configured to communicate with point of saleelements such as retail server 540 (FIG. 5) to receive transactioninformation including account identifying information and providedigital offer information as further described for FIG. 4 and in othersections herein. The point of sale interface logic 812 may, in someembodiments, interact with web server logic 822 to post or get requestsor responses using HTTP; alternatively, retail-specific communicationprotocols may be used.

The account identifying logic 814 is coupled to the point of saleinterface logic 812 to receive the account identifying information, andhas an implicit indirect connection to the OS 804, CPU 802, and datastore 512 for the purpose of issuing one or more database queries orother requests to determine if the account identifying information is inthe data store. The account identifying logic 814 is further coupled tooffer selection logic 816 for providing a request to form and send oneor more receipts or offers. The account identifying logic 814 may alsocouple to the SMTP daemon logic 820, POS logic 812 and/or web serverlogic 822 for the purpose of forming and sending an email, POS protocolcommunication, or HTTP post or response to the retail server 540 orclient 520 indicating that the account identifying information wasrecognized.

The offer availability logic 826 is coupled to the point of saleinterface logic 812 to receive the account identifying information, andhas an implicit indirect connection to the OS 804, CPU 802, and datastore 512 for the purpose of issuing one or more database queries orother requests to determine if the account identifying information isassociated with one or more digital coupons saved to an account in thedata store. The account identifying logic 814 may also couple to theSMTP daemon logic 820, POS logic 812 and/or web server logic 822 for thepurpose of forming and sending an email, POS protocol communication, orHTTP post or response to the retail server 540 or client 520 indicatingthat the account identifying information is associated with one or moredigital coupons saved to an account in the data store.

The offer selection logic 816 is configured to select one or more offersbased on a positive recognition of the account identifying informationand to signal the receipt forming logic 818 to form an electronicreceipt that contains the offers, links to the offers, call-outs for theoffers or other indications about how to obtain offers. The SMTP daemonlogic 820 is configured to implement an electronic mail protocol such assimple mail transport protocol (SMTP) and exposes an applicationprogramming interface (API) with which other elements of the system mayrequest sending emails and may receive, parse, and use the parts ofinbound received emails. The web server logic 822 is configured toimplement an HTTP server and to serve one or more stored HTML pages, orform and send one or more dynamically generated HTML pages, to theclient 520, offer providers 195, and/or retail server 540. The offerprovider interface logic 824 is configured to couple to offer providers195 and to interface with the web server logic 822 and suitable otheroffer provider application logic to enable offer providers to define andstore offers in data store 512, and to receive metrics about the use ofoffers in the described system.

Each element of logic of offer server computer 810 described above forFIG. 8 may comprise customized hard-wired logic, one or more ASICs orFPGAs, firmware and/or program logic which in combination with the dataprocessing system causes or programs computer 810 to be aspecial-purpose machine. According to one embodiment, the techniquesherein are performed by computer 810 in response to CPU 802 executingone or more sequences of one or more instructions contained in mainmemory. Such instructions may be read into main memory from anotherstorage medium, such as data store 512. Execution of the sequences ofinstructions contained in main memory causes CPU 802 to perform theprocess steps described herein. In alternative embodiments, hard-wiredcircuitry may be used in place of or in combination with softwareinstructions.

6.6. Data Store

Offer distributor 515 maintains the data supplied by offer providers 595as offer data in data store 512, which is coupled to offer server 510.Data store 512 may comprise one or more databases and/or filerepositories. The offer data may take a variety of forms, includingdatabase records and/or one or more files. Among other aspects, offerdata may comprise, for each offer, data such as the name of the offerprovider 595 making the offer, distribution parameters, terms of theoffer, print layout information and graphics, one or more internal orprovider identification numbers, bar code generation information, one ormore relevant uniform resource locators (URLs), one or more offer namesor titles, one or more related search terms, clearinghouse information,and one or more related categories. Distribution parameters may includeaggregate distribution limit values, per device distribution limitvalues, per region distribution limit values, and/or per clientdistribution limit values.

Data store 512 further stores consumer account data. The consumeraccount data includes data for one or more different consumer accounts,each of which may or may not be mapped to a unique consumer. Some or allof the consumer accounts may have been established during a registrationprocess with offer distributor 510. Some or all of the consumer accountsmay instead have been established with a retailer 545, e.g., during anonline or in-store registration process, and the details thereof mayhave been subsequently communicated by the retailer 545 to offerdistributor 510.

Regardless of how the consumer accounts came into existence, theconsumer account data specifies one or more account identifiers for eachconsumer account. The consumer account data may also specify orotherwise indicate one or more electronic addresses tied to eachaccount. Each account identifier may in turn be associated with dataidentifying one or more digital coupons that are available to aconsumer. Some or all of the one or more digital coupons may also beassociated with other account identifiers associated with the consumeraccount. In an embodiment, the digital coupons with which the accountidentifiers are associated are unique instances of corresponding offers,wherein each unique instance has a unique coupon identifier. Forexample, just as each coupon that may be printed by offer server 510 mayhave a unique coupon number, a unique coupon number may also begenerated each time a consumer saves a digital coupon to the consumer'saccount. However, in other embodiments, the digital coupons do notrequire unique coupon identifiers.

Data store 512 may also store other information related to offerdistribution, including device data and distribution logs. The devicedata describes a plurality of devices that execute clients for accessingoffer data, such as client 520. Each device may be described by a deviceidentifier. Device data may include information such as hardwareidentifiers, client identifiers, geographic information, and permissionsdata. In an embodiment, each device identifier is assigned based on avariety of characteristics of the device, in such a manner as to producedevice identifiers that are virtually guaranteed to be unique. In anembodiment, the characteristics from which the device identifier arederived include data that cannot easily be changed, so as to ensure thatno single device may print more than its allotted share of couponssimply by changing a network address, data file, computer name, oroperating system. In an embodiment, the characteristics from which thedevice identifiers are derived include hardware identifiers such asserial numbers. Techniques for assigning identifiers are described in,for example, U.S. Patent Publication Number 2010/0124235A1, publishedMay 20, 2010, the contents of which are hereby incorporated by referencefor all purposes as if fully set forth herein. In other embodiments,however, a device identifier may in fact be a network address, a Macaddress, a computer name, or a unique client identifier that isgenerated at the time the client is installed.

Distribution logs track the number of coupons that have been distributedfor each offer described in the offer data, including the number oftimes coupons have been printed and/or the number of times offers havebeen saved to a consumer account. Distribution logs may further trackhow many times each device described in the device data and/or how manytimes each consumer described in the consumer account data has printedcoupons for, viewed, and/or saved each offer described in offer data.

Data store 512 may also store a variety of compensation data. Forexample, data store 512 may store data indicating, for each offer, thenumber of times a retailer 545 has reported the offer as redeemed. Asanother example, data store 512 may store balances and account numbersof accounts established by providers 595 from which funds forcompensating retailer 545 are to be drawn. Data store 512 may furtherstore account numbers that should be credited in order to providecompensation to retailer 545. Data store 512 may further store a varietyof other accounting data.

6.7. Client

Client 520 may be any of a variety of devices, including a personalcomputer, printer, phone, or portable computing device. In anembodiment, client 520 comprises one or more application components thatprovide consumer 535 with an interface to offer server 510. Client 520may be, for example, a standalone software application, a web browser,or a plug-in to a web browser. Client 520 need not necessarily beexecuted by a device that is owned or even exclusively operated byconsumer 535. For example, client 520 may be executed by an in-storekiosk provided to consumers by retailer 545.

In an embodiment, client 520 is a special-purpose computer configuredwith logic that can perform the operations described herein duringoperation. In an embodiment, client 520 is a general-purpose computerthat comprises one or more processors, and memory, mass storage device,or other non-transitory computer-readable storage media storinginstructions which, when loaded and executed, cause the one or moreprocessors to perform the operations that are further described herein.

Client 520 communicates with offer server 510 over a network such as theInternet to receive offer data. The offer data sent to client 520 mayinclude, for instance, a listing of information about offers availableto consumer 535, including offer terms and values, as well as datadescribing a specific offer in sufficient detail to allow client 520 toprint a coupon for the offer at printer 529. Printer 529 is any printingdevice capable of printing a coupon. Printer 529 may be connected toclient 520 via any communication mechanism, or client 520 may beintegrated into printer 529.

Client 520 may, using various input or output mechanisms, allow consumer535 to view a list of available offers, select a particular offer fromthat list, and choose whether to print a coupon for the offer, or tosave the offer to consumer 535's account. In response to consumer 535selecting the latter option, client 520 may send a request to offerserver 510 to save the selected offer to consumer 535's account.

In an embodiment, multiple clients 520 may be available to a consumer,with each client 520 potentially supporting different mechanisms bywhich the consumer may access an offer. For example, one client 520 mayonly allow a consumer to print coupons via printer 529, another client520 may only allow a consumer to save digital coupons to an account, andanother client 520 may allow a consumer to access offers in both ways.

In an embodiment, offer data and instructions are sent to client 520from a server at an external website, such as a retail website, insteadof offer server 510. In such an embodiment, client-initiated requests tooffer server 510 may or may not be relayed through such an externalwebsite.

In an embodiment, client 520 includes logic for generating a deviceidentifier, as described in the previous section. Client 520 may reportthis device identifier to offer server 510 or retail server 540 uponrequest. Among other purposes, the device identifier may be used by theoffer server 510 for the purpose of enforcing per-device offerdistribution limits

In an embodiment, client 520 is a wireless, portable, and/or batterypowered computing device that the consumer commonly keeps with him orher while traveling, such as a phone, tablet, personal digitalassistant, watch, and so forth. Client 520 is configured to executeinstructions for a graphical coupon client interface by which theconsumer communicates with offer server 510. The coupon client interfacemay be provided by, for instance, a mobile application or a webapplication.

In an embodiment, client 520 is further configured to executeinstructions for a graphical mobile payment interface by which theconsumer communicates with a payment server during transactions withterminal 542. The mobile payment interface and coupon client interfacemay be integrated or separate. The interfaces may be activated byconsumer input such as launching an application or selecting a link inan email, in response to unsolicited communications from offer server510, the payment server, and/or in response to signals received fromterminal 530. Client 520 may include communication interfaces by whichclient 520 is capable of communicating with terminal 542 during thetransaction to effect payment, receive receipt data, and receive offerinformation about available offers upon completion of the transaction.Any suitable communication interface or combination of communicationinterfaces may be used, including Wi-Fi, cellular data, Bluetooth,Near-Field Communication, and so forth.

In an embodiment, client 520 is further configured to executeinstructions for a receipt viewing and management interface by which theconsumer views receipts for transactions between the consumer and one ormore retailers. The receipt viewing and management interface may beintegrated with or separate from any mobile payment interface and couponclient interface.

6.8. Account Identifiers

Account identifier 532 is a series of characters and/or symbols thatuniquely identifies consumer 535 or a consumer account associated withconsumer 535. For example, account identifier 532 may identify aretailer's loyalty account, a consumer account with offer distributor515, or both. In the latter case, for instance, account identifier 532may have been created to identify the retailer's loyalty account, butthen subsequently registered with the offer distributor account, alongwith potentially other identifiers. Account identifier 532 may or maynot also identify or be identified from a physical item, such as a cardor personal computing device. In an embodiment, the physical item is anyportable item that has an account identifier that can be readilyaccessed during a transaction.

In an embodiment, account identifier 532 is a number for a card account,such as a credit card account or consumer loyalty card account. Consumer535 may provide identifier 532 during a transaction by, for example,scanning the card at a card reader, typing or stating the numbers on thecard, or providing personal information by which the card number may belocated, such as a telephone number.

In an embodiment, account identifier 532 is a unique device identifierbelonging to a portable computing device. Examples include a mobilephone, laptop or netbook computer, tablet computer, personal digitalassistant, flash drive, music player, or camera. For example, the deviceidentifier may be a MAC address, Bluetooth address, serial number,randomly assigned number, and so forth. Consumer 535 may provideidentifier 532 during a transaction by, for example, allowing theportable device to broadcast identifier 532 wirelessly to the retailer'scheckout system, allowing the retailer to scan the device, or allowingthe retailer to see or scan information displayed by the device. In anembodiment, identifier 532 does not necessarily correspond to devicehardware, but may rather be provided by a software application executingon the device.

In an embodiment, account identifier 532 is emitted wirelessly by aradio-frequency identifying (RFID) chip or any other mechanism capableof transmitting signals that may be detected during a transaction withretailer 545. For example, the RFID chip may be embedded within a card,device, or other item carried by consumer 535. The RFID chip may be, forexample, a passive NFC tag or active NFC reader.

In an embodiment, offer distributor 510 allows consumer 535 to printaccount identifier 532, or a barcode representation thereof, on a sheetof paper. The paper may then be presented to the retailer 545 during atransaction. Using this approach, consumer 535 can take advantage of thetechniques described herein without having to remember accountidentifier 532 and without having to present to the retailer 545 anidentifying card or device. The paper may or may not be reusable indifferent transactions at the same or at a different retailer.

In an embodiment, account identifier 532 may be associated withbiometric data that uniquely identifies consumer 535, such as afingerprint or a retinal scan. Thus, the consumer may provide theidentifier in an embodiment by allowing a retailer to scan consumer 535for the biometric data.

6.9. Variations and Alternatives

System 500 as shown in FIG. 5 presents only one embodiment in which thetechniques described herein may be practiced. Other embodiments mayinclude additional and/or fewer elements, in potentially differentarrangements. As an example, any of offer provider 595, offerdistributor 515, or retailer 545, may be the same entity, and variousother components may therefore be omitted. Furthermore, variousprocesses, such as generating and sending electronic receipts orlocating consumer account information, may be performed by a serverprovided by yet a different entity, such as a payment provider orshopping incentive provider, that is not depicted in FIG. 5. Moreover,neither printer 529 nor printing component 549 is necessary to practicemany of the techniques described herein, as some embodiments do notinclude capabilities for printing receipts and/or printing coupons.

7.0. Implementation Mechanism—Hardware Overview

According to one embodiment, the techniques described herein areimplemented by one or more data processing systems, includinggeneral-purpose computing devices or special-purpose computing devices.

In general, data processing systems that may be used in connection withvarious embodiments include a desktop computer, laptop computer,netbook, electronic notebook, ultra mobile personal computer (UMPC),electronic tablet or similar device (including any tablet using an iOS™operating system released by Apple Computer™, Android™ operating systemreleased by Google Inc.™ or Windows™ operating system released byMicrosoft Corporation™), client computing device, client terminal,client console, server computer, server system, server terminal, cloudcomputing system, parallel processing or other distributed computingsystem, virtual machine, remote computer, mobile telephone, smartphoneor similar device (including any smartphone using an iOS™ operatingsystem released by Apple Computer™, Android™ operating system releasedby Google Inc.™ or Windows™ operating system released by MicrosoftCorporation™), wearable computer, head mounted computer or display,personal digital assistant, personal digital organizer, handheld device,networking device, or any other device, component, module, subsystem orsystem capable of processing electronic data, or any combination of theforegoing.

Data processing systems that may be used in connection with variousembodiments may be hard-wired to perform the techniques, or may includedigital electronic devices such as one or more application-specificintegrated circuits (ASICs) or field programmable gate arrays (FPGAs)that are persistently programmed to perform the techniques, or mayinclude one or more general purpose data processors programmed to runsoftware, including program instructions in firmware, memory, otherstorage, or a combination. Such data processing systems may also combinecustom hard-wired logic, ASICs, or FPGAs with custom programming toperform their functions.

In various embodiments, a data processing system may include one or morelogic modules, sometimes also denoted data processing modules ormodules. In various embodiments, a logic module may consist of (a) anysoftware application, (b) any portion of any software application, wheresuch portion can process data, (c) any data processing system, (d) anycomponent or portion of any data processing system, where such componentor portion can process data, and (e) any combination of the foregoing.In general, a logic module may be configured to perform instructions andto carry out the functionality of one or more embodiments, whether aloneor in combination with other data processing modules or with otherdevices or applications. In general, a data processing system mayinclude one or more logic modules. Depending on the implementation, alogic module may be construed itself to be a data processing system interms of architecture, configuration, functionality, performance and/orother attributes.

As an example of a logic module comprising software, a logic module mayconsist of, or may include a software application, and the softwareapplication may itself consist of one or more software programs and/orsoftware modules. A logic module consisting of software may perform oneor more functions if loaded on a data processing system that comprises aprocessor or on a logic module that comprises a data processor.

As an example of a logic module comprising hardware, a data processor, adynamic memory and a storage memory may be included in a logic module toprovide a hardware execution platform for software. Examples of dataprocessing systems that may incorporate both logic modules comprisingsoftware and logic modules comprising hardware include a desktopcomputer, a mobile computer, a handheld device, or a server computer,each being capable of running software to perform one or more functionsdefined in the respective software.

In various embodiments, functionality of logic modules may beconsolidated in fewer logic modules (e.g., in a single logic module), ormay be distributed among a larger set of logic modules. For example,separate logic modules performing a specific set of functions may beequivalent with fewer or a single logic module performing the same setof functions. Conversely, a single logic module performing a set offunctions may be equivalent with a plurality of logic modules thattogether perform the same set of functions. In various embodiments, twoor more logic modules may be independent modules and may performspecific functions independent of each other, or may be combined inwhole or in part in a single module that singularly performs theircombined functionality.

In one embodiment, the functionality of one more logic modules may bedistributed among any number of logic modules. One way to distributefunctionality of one or more original logic modules among substitutelogic modules is to reconfigure the software and/or hardware componentsof the original logic modules. Another way to distribute functionalityof one or more original logic modules among different substitute logicmodules is to reconfigure software executing on the original logicmodules so that it executes in a different configuration on thesubstitute logic modules while still achieving substantially the samefunctionality. Examples of logic modules that may incorporate thefunctionality of multiple logic modules and therefore can be construedthemselves as logic modules include a system-on-a-chip (SoC) device anda package-on-package (PoP) device, where the integration of logicmodules may be achieved in a planar direction (e.g., a processor and astorage memory disposed in the same general layer of a packaged device)and/or in a vertical direction (e.g. using two or more stacked layers).

For example, FIG. 9 is a block diagram that illustrates a dataprocessing system 900 that may be used in connection with variousembodiments. Data processing system 900 includes a bus 902 or othercommunication mechanism for communicating information, and a dataprocessor 904 coupled with bus 902 for processing information.

A data processor, such as the data processor 904 from FIG. 9, sometimesdenoted processor, represents one or more general-purpose dataprocessing devices such as a microprocessor or other central processingunit. A data processor may be a complex instruction set computing (CISC)microprocessor, a reduced instruction set computing (RISC)microprocessor, a very long instruction word (VLIW) microprocessor, aprocessor implementing other instruction sets, or a processorimplementing a combination of instruction sets, whether in a single coreor in a multiple core architecture. Data processor 904 may also be orinclude one or more special-purpose processing devices such as anapplication specific integrated circuit (ASIC), a field programmablegate array (FPGA), a digital signal processor (DSP), network processor,any other embedded processor, or the like. The data processor 904 mayexecute instructions for performing operations and steps in connectionwith various embodiments.

Data processing system 900 may also include a main memory 906, such as adynamic memory designed to provide higher data access speeds, coupled tobus 902 for storing information and instructions to be executed byprocessor 904. Main memory 906 also may be used for storing temporaryvariables or other intermediate information during execution ofinstructions to be executed by processor 904. Such instructions, whenstored in non-transitory storage media accessible to processor 904,render data processing system 900 into a special-purpose machine that iscustomized to perform the operations specified in the instructions.Examples of main memory 906 include dynamic random access memory (DRAM),synchronous DRAM (SDRAM) memory, read-only memory (ROM) and flashmemory. The main memory 906 may be adapted to store all or part of theinstructions of a software application, as these instructions are beingexecuted or may be scheduled for execution by data processor 904. Insome implementations, the main memory 906 may include one or more cachememory systems that are designed to facilitate lower latency data accessby the data processor 904.

Data processing system 900 may further include a read only memory (ROM)908 and/or a storage device 910 coupled to bus 902.

In general, the storage device 910, also sometimes denoted a storagememory, may be designed to store larger amounts of data. Examples ofsuch storage memories include a magnetic hard disk and a flash memorymodule. In various implementations, a data processing system may alsoinclude, or may otherwise be configured to access one or more externalstorage memories, such as an external memory database or other memorydata bank, which may either be accessible via a local connection (e.g.,a wired or wireless USB, Bluetooth, or WiFi interface), or via a network(e.g., a remote cloud-based memory volume).

In general, the terms “memory,” “memory medium,” or “memory device”could be used to refer to any computer readable storage medium, storagememory, dynamic or static memory, or other memory device, including themain memory 906, the ROM memory 908 and the storage device 910 shown inFIG. 9. A memory may include any chip, disk, device, combination ofchips and/or devices, or other structure capable of storing electronicinformation, whether temporarily, permanently or quasi-permanently. Amemory could be based on any magnetic, optical, electrical, mechanical,electromechanical, MEMS, quantum, or chemical technology, or any othertechnology or combination of the foregoing that is capable of storingelectronic information. Examples of memory include a magnetic hard disk,a random access memory (RAM) module, an optical disk (e.g., DVD, CD), aflash memory card, stick, disk or module, or any combination of one ormore of the foregoing. A memory could be centralized, distributed,local, remote, portable, or any combination of the foregoing. A memorycould consist of a stand-alone or discrete memory storage device, orcould be an array of distributed storage devices.

A software application or module, and any other computer executableinstructions, may be stored on any such memory, whether permanently ortemporarily, including on any type of disk (e.g., a floppy disk, opticaldisk, CD-ROM, and other magnetic-optical disks), read-only memory (ROM),random access memory (RAM), EPROM, EEPROM, magnetic or optical card, orany other type of media suitable for storing electronic instructions.

In general, a memory could host a database, or a part of a database.Conversely, in general, a database could be stored completely on aparticular memory, could be distributed across a plurality of memories,or could be stored on one particular memory and backed up or otherwisereplicated over a set of other memories. Examples of databases includeoperational databases, analytical databases, data warehouses,distributed databases, end-user databases, external databases,hypermedia databases, navigational databases, in-memory databases,document-oriented databases, real-time databases and relationaldatabases. One or more databases could be stored in a data farm or incloud memory system.

A memory may store one or more software applications, in whole or inpart. In general, a software application, also denoted a data processingapplication or an application, may include any software application,software module, function, procedure, method, class, process, or anyother set of software instructions, whether implemented in programmingcode, firmware, or any combination of the foregoing. A softwareapplication may be in source code, assembly code, object code, or anyother format. In various implementations, an application may run on morethan one data processing system (e.g., using a distributed dataprocessing model or operating in a computing cloud), or may run on aparticular data processing system or logic module and may output datathrough one or more other data processing systems or logic modules.

Data processing system 900 may be coupled to a display 912, possibly viabus 902. Display 912 enables a user to visualize data output by the dataprocessing system 900 and/or to interact with the data processing system900. The display 912 may directly or indirectly provide a graphical userinterface (GUI) adapted to facilitate presentation of data to a userand/or to accept input from a user. The display 912 may represent one ormore stand-alone, integrated, external or remote displays, including anyLCD, LED or CRT display, optical projection device, holographicdisplays, wearable personal display (e.g. an electronic eye weardisplay), or of a combination of the foregoing.

A visual display may also be denoted a graphic display, computerdisplay, display, computer screen, screen, computer panel, or panel.Other examples of displays include a computer monitor, an integratedcomputer display, electronic paper, a flexible display, a touch panel, atransparent display, and a three dimensional (3D) display that may ormay not require a user to wear assistive 3D glasses.

A data processing system may incorporate a graphic display. Examples ofsuch data processing systems include a laptop, a computer pad ornotepad, a tablet computer, a smartphone, an electronic reader (alsodenoted an e-reader or ereader), or a personal data assistant (PDA).

A data processing system may be connected to an external graphicdisplay. Examples of such data processing systems include a desktopcomputer, a server, an embedded data processing system, or any otherdata processing system that does not itself include a display but whichproduces data that may be shown to a user. A data processing system thatincorporates a graphic display may also be connected to an externaldisplay. A data processing system may directly display data on anexternal display, or may transmit data to other data processing systemsor logic modules that will eventually display data on an externaldisplay.

Graphic displays may include an active display, passive display, LCDdisplay, LED display, OLED display, plasma display, and any other typeof visual display that is capable of displaying electronic informationto a user. Such graphic displays may permit direct interaction with auser, either through direct touch by the user (e.g. a touch-screendisplay that can sense a user's finger touching a particular area of thedisplay), through proximity interaction with a user (e.g., sensing auser's finger being in proximity to a particular area of the display),or through a stylus or other input device. In one implementation, thedisplay 912 is a touch-screen display that displays a human GUIinterface to a user, with the user being able to control the dataprocessing system 900 through the human GUI interface, or to otherwiseinteract with, or input data into the data processing system 900 throughthe human GUI interface.

An input device 914, which may include a physical or virtual keyboard orother device for entering information, may also be coupled to bus 902for entering information and command into data processing system 900.Another type of user input device is cursor control 916, such as amouse, a trackball, or cursor direction keys for communicating directioninformation and command selections to processor 904 and for controllingcursor movement on display 912. This input device typically has twodegrees of freedom in two axes, a first axis (e.g., x) and a second axis(e.g., y), that allows the device to specify positions in a plane.

Data processing system 900 may perform functionality in connection withvarious embodiments using customized hard-wired logic, one or more ASICsor FPGAs, firmware and/or software which help data processing system 900function as a special-purpose machine. According to one embodiment, dataprocessing system 900 achieves desired functionality in response toprocessor 904 executing one or more sequences of one or moreinstructions contained in a memory, such as main memory 906, ROM 908and/or storage device 910. Such instructions may be read into mainmemory 906 from another storage medium, such as storage device 910.Execution of the sequences of instructions contained in a memory maycause processor 904 to perform the process steps described herein. Inalternative embodiments, hard-wired circuitry may be used in place of orin combination with software instructions.

Other examples of a memory that may be used in connection with variousembodiments to store information and/or software include non-transitorymedia that store data and/or instructions that cause a machine tooperate in a specific fashion. Storage media that may be used as memoryin connection with various embodiments may comprise non-volatile mediaand/or volatile media. Non-volatile media may include, for example,optical or magnetic disks. Volatile media may include dynamic memory.Common forms of computer readable storage media include, for example, afloppy disk, a flexible disk, hard disk, solid state drive, magnetictape, or any other magnetic data storage medium, a CD-ROM, any otheroptical data storage medium, any physical medium with patterns of holes,a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip orcartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics. Transmissionmedia can also take the form of acoustic or light waves, such as thosegenerated during radio-wave and infra-red data communications.

In various implementations, bus 902 may be implemented using a varietyof transmission media, including metallic wires, optic connections, orwireless connections. In some implementations, there may be one or moredata buses in addition to the data bus 902 that connect some or all ofthe components of data processing system 900, including possiblydedicated data buses that connect only a subset of such components. Eachsuch data bus may implement open industry protocols (e.g., a PCI orPCI-Express data bus), or may implement proprietary protocols.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 904 for execution. For example,the instructions may initially be carried on a magnetic disk or solidstate drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to data processing system900 can receive the data on the telephone line and use an infra-redtransmitter to convert the data to an infra-red signal. An infra-reddetector can receive the data carried in the infra-red signal andappropriate circuitry can place the data on bus 902. Bus 902 carries thedata to main memory 906, from which processor 904 retrieves and executesthe instructions. The instructions received by main memory 906 mayoptionally be stored on storage device 910 either before or afterexecution by processor 904.

The data processing system 900 may further include an audio interface,which provides the ability for the data processing system 900 to outputsound (e.g., a speaker), to input sound (e.g., a microphone), or anycombination of the foregoing. In some implementations, an audio port maybe used to transmit data to and from the data processing system 900,either through sound wave modulation (e.g., emulating the operation of amicrophone, although possibly in different frequency ranges and withdifferent data encoding protocols), or through modulation of theelectrical signals otherwise transmitted through the audio port (e.g.,by using an input microphone port or headset connector port to transmitelectrical signals that are properly encoded and/or modulated).

The data processing system 900 may further include any other componentsthat may be advantageously used in connection with receiving, processingand/or transmitting information.

Data processing system 900 also includes a communication interface 918coupled to bus 902. Communication interface 918 may provide a two-waydata communication coupling to a network link 920 that is connected to alocal network 922. For example, communication interface 918 may be anintegrated services digital network (ISDN) card, cable modem, wirelessmodem, satellite modem, or a modem to provide a data communicationconnection to a corresponding type of telephone line. As anotherexample, communication interface 918 may be a local area network (LAN)card to provide a data communication connection to a compatible LAN.Wireless links may also be implemented. In such an implementation,communication interface 918 may send and/or receive electrical,electromagnetic and/or optical signals that carry analog or digital datastreams representing various types of information.

Network link 920 may provide data communication through one or morenetworks to other data devices. For example, network link 920 mayprovide a connection through local network 922 to a host computer 924 orto data equipment operated by an Internet Service Provider (ISP) 926.ISP 926 in turn may provide data communication services through theworld wide packet data communication network commonly referred to as theInternet 928. Local network 922 and Internet 928 may use electrical,electromagnetic and/or optical signals that carry digital data streams.The signals through the various networks and the signals on network link920 and through communication interface 918, which carry the digitaldata to and from data processing system 900, are example forms oftransmission media.

Data processing system 900 may send messages and/or receive data,including program code, through the network(s), network link 920 andcommunication interface 918. In the Internet example, a server 930 mighttransmit a requested code for an application program interface throughInternet 928, ISP 926, local network 922 and communication interface918. The received code may be executed by processor 904 as it isreceived, and/or stored in storage device 910, or other non-volatilestorage for later execution.

In various embodiments, a data processing system, such as the dataprocessing system 900, may communicate, via one or more communicationchannels and/or one or more communication networks, with local or remoteperipherals, logic modules and/or data processing systems. For example,with reference to the data processing system illustrated in FIG. 9. suchcommunications could be carried out through the communication interface918, in which case the communication interface 918 and/or other logicmodules could be configured to include the appropriate communicationhardware and software logic to implement the appropriate data encoding,decoding, encryption, decryption, and/or other communicationfunctionality.

In various embodiments, a data processing system may communicatedirectly with other data processing systems (e.g., a retail terminalcommunicating with a remote server) or with logic modules (e.g., a localcredit card reader, a bar scanner, other point of sale peripherals,etc.) via one or more communication channels and/or via one or morenetworks.

In various embodiments, a communication channel may include any director indirect data connection path, including any connection using awireless technology (e.g., Bluetooth, infrared, WiFi, WiMAX, cellular,3G, 4G, EDGE, CDMA and DECT), any connection using wired technology(including via any serial, parallel, wired packet-based communicationprotocol (e.g., Ethernet, USB, FireWire, etc.), or other wirelineconnection), any optical channel (e.g., via a fiber optic connection orvia a line-of-sight laser or LED connection), and any otherpoint-to-point connection capable of transmitting data.

In various embodiments, a network may include one or more communicationchannels. In general, a network, or data network, consists of one ormore communication channels. Examples of networks include LANs, MANs,WANs, cellular and mobile telephony networks, the Internet, the WorldWide Web, and any other information transmission network. In variousimplementations, a data processing system may include multipleinterfaces and communication ports capable of connecting to multiplecommunication channels and/or networks.

In various embodiments, a data processing system may transmitinformation and/or receive information via one or more networks thatfacilitate communications at longer distances. In various embodiments,each network that facilitates data communications for data processingsystems and logic modules may be, or may include, a 3G network, a 4Gnetwork, an EDGE network, a CDMA network, a GSM network, a 3GSM network,a GPRS network, an EV-DO network, a TDMA network, an iDEN network, aDECT network, a UMTS network, a WiMAX network, a cellular network, anytype of wireless network that uses a TCP/IP protocol or other type ofdata packet or routing protocol, any other type of wireless wide areanetwork (WAN) or wireless metropolitan area network (MAN), or asatellite communication channel or network. Each of the foregoing typesof networks that could be used to transmit or receive information fromdata processing systems and logic modules utilizes various communicationprotocols, including protocols for establishing connections,transmitting and receiving data, handling various types of datacommunications (e.g., voice, data files, HTTP data, images, binary data,encrypted data, etc.), and otherwise managing data communications. Invarious embodiments, a data processing system may be configured to becompliant with one or more protocols used in a network, such that therespective data processing system can successfully connect to thenetwork and communicate via the network with other data processingsystems or logic modules.

In various embodiments, a data processing system may transmitinformation and/or receive information via one or more local networksthat facilitate communications at shorter distances. For example, a dataprocessing system (e.g., a point of sale checkout terminal) located in aretailer or other commercial facility may communicate with another dataprocessing system (e.g., a customer's smartphone) and/or with a logicmodule (e.g., a point of sale peripheral) via a local area network (aLAN). In various embodiments, a local area network may be, or mayinclude, a wired LAN (e.g., an Ethernet network, an optical network,etc.), or a local wireless network (e.g., a WiFi network).

In one embodiment, a data processing system may communicate with anotherdata processing system or logic module that is located in physicalproximity through a personal area network. For example, a point of saleterminal may communicate with a loyalty card reader via a Bluetoothconnection to receive information relating to the loyalty card, or maycommunicate with a customer's smartphone via a near field communicationchannel to transmit or receive a digital coupon or offer or customeridentification data.

In one embodiment, a personal area network is implemented so that it hasa limited distance range. An advantage of using a limited-rangeconnection between one or more data processing systems and/or one ormore logic modules is that two devices would have to be located in closeproximity to be able to connect, which means that the security ofcommunications can be correspondingly increased. It would be less likelythat a hostile device could be brought on the premises and placed inclose physical proximity of a data processing system used in connectionwith various embodiments to attempt to compromise the security of thedata processing system.

In one embodiment, the personal area network has a high security level.In one embodiment, a high security level for the connection between adata processing system (e.g., a point of sale checkout terminal) andanother data processing system (e.g., a customer's smartphone) or logicmodule (e.g., a point of sale peripheral) can be achieved byimplementing a pairing mechanism before the two devices acknowledge eachother and initiate trusted data communications. In one embodiment, ahigh security level for a personal area connection can be achieved byencrypting communications before the respective data processing systemsand/or logic modules.

In various embodiments, examples of logic modules and/or data processingsystems that may be in communication with a data processing systemdeployed in a retailer or other commercial facility include a peripheraldevice, such as a cash register, a coin dispenser, a credit card reader,a barcode scanner, a printer, a document scanner, an RFID receiverconfigured to receive payment-related information from an RFID-enableddevice, an image recognition device capable of identifying an object, aphoto camera, or a video camera. In various embodiments, there may betwo or more peripheral devices, directly or indirectly communicated to adata processing system deployed in a retailer or other commercialfacility.

In one embodiment, the personal area network used to transmit or receiveinformation from a data processing system and/or logic module (e.g., aperipheral device) is a Bluetooth communication network. Bluetooth is aproprietary open wireless technology standard for exchanging data overshort distances. The Bluetooth standard is managed by the BluetoothSpecial Interest Group. Current Bluetooth specifications usefrequency-hopping spread spectrum in the range 2,400-2,483.5 MHz. Otherfrequency use protocols and/or frequency bands may be used inalternative or future implementations.

In one implementation, more than one simultaneous connection isestablished between a data processing system and one or more other dataprocessing systems or logic modules via a personal area network, whichmay increase the reliability and/or speed of the communications betweenthe respective devices. In one embodiment, a single Bluetooth connectionis established between two devices. In other embodiments, two or threesimultaneous Bluetooth connection are established between two devices.

In various embodiments, a personal area network and/or a connectionestablished between a data processing system and one or more logicmodules is, or includes, one of the following: a piconet (e.g., anad-hoc network linking two or more wireless devices over a shortdistance radius), a scatternet (e.g., an ad-hoc network consisting oftwo or more piconets), a wireless USB network or connection, a Z-Wavenetwork or connection, a ZigBee network or connection, an infrarednetwork or connection, a near field communication (NFC) network orconnection, a radio-frequency identification (RFID) network orconnection, an optical signal carrier network or connection (e.g., aconnection using modulation of a light carrier (e.g., by an LED, diodeor laser) as the basis for data transmission, or any other wirelessnetwork or connection that can transmit data with sufficientreliability, speed and security over a short distance.

In general, unless otherwise stated or required by the context, whenused in connection with a method or process, data processing system, orlogic module, the words “adapted” and “configured” are intended todescribe that the respective method, data processing system or logicmodule is capable of performing the respective functions by beingappropriately adapted or configured (e.g., via programming, via theaddition of relevant components or interfaces, etc.), but are notintended to suggest that the respective method, data processing systemor logic module is not capable of performing other functions. Forexample, unless otherwise expressly stated, a logic module that isdescribed as being adapted to process a specific class of informationwill not be construed to be exclusively adapted to process only thatspecific class of information, but may in fact, depending on thecircumstances, be able to process other classes of information and toperform additional functions (e.g., receiving, transmitting, converting,or otherwise processing or manipulating information).

Some of the embodiments described in this specification may be presentedin terms of algorithms and symbolic representations of operations ondata bits within a computer memory. In general, an algorithm representsa sequence of steps leading to a desired result. Such steps generallyrequire physical manipulations of physical quantities. Usually, althoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated using appropriate electronicdevices. Such signals may be denoted as bits, values, elements, symbols,characters, terms, numbers, or using other similar terminology.

When used in connection with the manipulation of electronic data, termssuch as processing, computing, calculating, determining, displaying, orthe like, generally refer to the action and processes of a dataprocessing system or logic module that manipulates and transforms datarepresented as physical (electronic) quantities within the registers andmemory of such system or module, into other data similarly representedas physical quantities within the registers or memory of that system ormodule, or within the registers or memory of other data processingsystems or logic modules.

Various embodiments may be implemented using an apparatus or machinethat executes programming instructions. Such an apparatus or machine maybe specially constructed for the required purposes, or may comprise ageneral purpose computer selectively activated or reconfigured by asoftware application.

Algorithms discussed in connection with various embodiments of thepresent invention are not inherently related to any particular computeror other apparatus. Various general purpose systems may be used withprograms in accordance with various embodiments, or it may proveconvenient to construct more specialized apparatus to perform therequired method steps. The required structure for a variety of thesesystems will appear from the description provided in connection with thevarious embodiments discussed herein. In addition, unless otherwiseexpressly stated, embodiments are generally not described with referenceto any particular programming language, data transmission protocol, ordata storage protocol, and a variety of programming languages,transmission or storage protocols may be used if appropriate under thecircumstances.

As used in this specification, a set means any group of one, two or moreitems. Analogously, a subset means, with respect to a set of N items(where N is at least 2), any group of such items consisting of N−1 orless of the respective N items.

As used in this specification, the terms “include,” “including,” “forexample,” “exemplary,” “e.g.,” and variations thereof, are not intendedto be terms of limitation, but rather are intended to be followed by thewords “without limitation” or by words with a similar meaning.Definitions in this specification, and all headers, titles andsubtitles, are intended to be descriptive and illustrative with the goalof facilitating comprehension, but are not intended to be limiting withrespect to the scope of the inventions as recited in the claims. Eachsuch definition is intended to also capture additional equivalent items,technologies or terms that would be known or would become known to aperson of average skill in this art as equivalent or otherwiseinterchangeable with the respective item, technology or term so defined.

Unless otherwise required by the context, the verb “may” or “could”indicates a possibility that the respective action, step orimplementation may or could be achieved, but is not intended toestablish a requirement that such action, step or implementation mustoccur, or that the respective action, step or implementation must beachieved in the exact manner described.

8.0. Extensions and Alternatives

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromembodiment to embodiment, and from implementation to implementation. Thescope of the invention is described in the claims that issue from thisdisclosure, in the specific form in which such claims issue, includingany subsequent correction, and is not intended to be limited to anyparticular embodiment or implementation beyond any limitations expresslydefined in such claims. Any definitions expressly set forth herein forterms contained in such claims shall govern the meaning of such terms asused in the claims. Hence, no limitation, element, property, feature,advantage or attribute that is not expressly recited in a claim shouldlimit the scope of such claim in any way. The specification and drawingsare, accordingly, to be regarded in an illustrative rather than arestrictive sense.

8.1. Selecting Offers Based on Collected Transaction Logs

According to an embodiment, a method comprises: storing offer datadescribing a plurality of offers for a plurality of different items;providing, over a first network, to each retailer of a plurality ofretailers, a transaction interface; receiving transaction details for aplurality of transactions from the plurality of retailers via thetransaction interface, the transaction details including, for eachtransaction of the plurality of transactions, line item details for eachitem of a plurality of items purchased in the transaction; storing thetransaction details; providing, over a second network, to at least afirst retailer of the plurality of retailers, an offer recommendationinterface; receiving via the offer recommendation interface, from thefirst retailer, a request for offer recommendations, the requestincluding contextual data; matching the contextual data to a set oftransactions described in the transaction details for the plurality oftransactions; based on line item details from the matched set oftransactions, selecting one or more offers from the plurality of offersin response to the request; and responsive to the request, providing thefirst retailer with offer data describing the selected one or moreoffers. In various embodiments, one or more data processing systemsand/or one or more logic modules may perform all or a subset of theforegoing steps.

In an embodiment, the selection includes identifying, based on the lineitem details for one or more transactions, one or more items associatedwith the contextual data; and selecting offers based on those items. Inan embodiment, the selection includes selecting one or more consumersbased on information in contextual data; identifying transaction detailsfor one or more transactions associated with the one or more consumers;and selecting the one or more offers based on the transaction detailsfor the one or more transactions associated with the one or moreconsumers. In an embodiment, the contextual data includes consumeridentifiers, location data, basket items, a transaction number, and/orother contextual data described herein. In an embodiment, the firstnetwork is the second network.

In an embodiment, the retailer requests a consumer entity identifier orother information from the offer server via a consumer resolutioninterface. In an embodiment, the request is for a receipt, andresponding to the request includes returning the offer data withinreceipt data. In an embodiment, the receipt is formatted according totemplate indicated or provided by the first retailer. In an embodiment,the transaction details include redeemed offers. In an embodiment, thefirst retailer delivers the provided offers to a consumer via a websitebelonging to the first retailer. In an embodiment, the one or moreoffers include targeted offers targeted to a specific context. In anembodiment, the one or more offers include recommended offers rankedbased on signals derived from a specific context. In an embodiment, themethod further comprises the offer server subsequently receiving andresponding to requests to activate the one or more offers. In anembodiment, the offer server responds to the requests with activationdata to facilitate redemption at any of the plurality of retailers.

In an embodiment, the method further comprises, identifying a particularoffer based on the transaction details, calculating an estimatedretailer profit metric for showing the particular offer within a contextdescribed by the contextual data, and selecting the particular offerbased thereon. In an embodiment, the estimated retailer profit metric isa score from a scoring function optimized for maximizing estimatedretailer profit. In an embodiment, the selecting comprises, based on thetransaction details, calculating an estimated revenue per impression orrevenue per activation metric for showing a particular offer within acontext described by the contextual data, and selecting the one or moreoffers based thereon. In an embodiment, the estimated revenue perimpression or revenue per activation is a score from a scoring functionoptimized for maximizing revenue per impression or revenue peractivation.

8.2. Consumer Identification

According to an embodiment, a method comprises: receiving multiplesource collections of consumer records from multiple sources, whereinthe multiple sources include a first entity and a second entity that isdifferent from the first entity, wherein the multiple source collectionsinclude a first collection from the first entity and a second collectionfrom the second entity; wherein each particular collection of themultiple source collections has a corresponding particular consumerrecord structure, each particular consumer record structure havingparticular fields for which one or more of the consumer records in theparticular collection have values; for each particular collection of themultiple source collections, assigning trust scores to the particularfields of the particular collection, wherein at least a first field ofthe first collection has a different trust score than a similar secondfield of the second collection; based at least in part on the trustscores, establishing correlations between different consumer records indifferent collections of the multiple source collections by correlatingconsumer records that have similar values for one or more similarfields; generating a master collection of consumer records by generatingmaster consumer records based on the correlations, wherein each of aplurality of master consumer records is linked to at least two differentcorrelated consumer records from at least two different sources;receiving a message comprising consumer context data; selecting aparticular master consumer record to associate with the message, basedon comparing the consumer context data in the message to the masterconsumer records; and providing offer data in response to the message,based on consumer logs associated with the particular master consumerrecord. In various embodiments, one or more data processing systemsand/or one or more logic modules may perform all or a subset of theforegoing steps.

In an embodiment, providing the offer data comprises providingrecommended offers selected based on one or more activities associatedwith the particular master consumer record. In an embodiment, the offerdata is included with receipt data that the message requests. In anembodiment, providing the offer data comprises identifying offerstargeted to the particular master consumer record based on one or moreof: one or more activities associated with the particular masterconsumer record, or consumer attributes associated with the particularmaster consumer record. In an embodiment, providing offer data comprisesdetermining whether an offer has previously been activated inassociation with the particular master consumer record. In anembodiment, providing offer data comprises providing a list of offersthat have been activated for the consumer. The request is from aretailer, and the consumer context data is credentials supplied byconsumer during a transaction. In an embodiment, the message istransaction log.

In an embodiment, the selecting comprises selecting multiple masterrecords and scoring the likelihood that the context data belongs to aparticular record. In an embodiment, the selecting is further based onconfidence scores that indicate the frequency with which a particularvalue occurs in a particular field of a consumer's correlated consumerrecords. In an embodiment, the trust scores evolve over time based onone or more of: updates from the multiple sources, new transaction data,or confidence scores that indicate the frequency with which a particularvalue occurs in a particular field of a consumer's correlated consumerrecords.

In an embodiment, the method further comprises correlating transactionsfrom a plurality of different stores with the particular master consumerrecord. In an embodiment, the method further comprises receiving updatesto the multiple source collections from retailers over time, andrevising the correlations based thereon. In an embodiment, each value ofeach of the master consumer records is linked to a particular source ofthe multiple source collections from which the value originated. In anembodiment, the particular fields include aggregated transaction data.

In an embodiment, the selecting comprises identifying one or more valuesfor a particular field of the particular master consumer record based atleast on: a first value for the first field in a first consumer recordof the first collection, a second value for the second field in a secondconsumer record of the second collection, and the different trust scoresassigned to the first field and the second field. In an embodiment,identifying the one or more values comprises, in response to a querythat requests the one or more values for the particular field, queryingthe first consumer record for the first value, querying the secondconsumer record for the second value, and deciding which one or morevalues of the first value and the second value to return based at leaston the different trust scores. In an embodiment, identifying the one ormore values comprises, deciding which one or more values of the firstvalue and the second value to store in the master consumer record basedat least on the different trust scores.

In an embodiment, the first collection has a first consumer recordstructure and the second collection has a second consumer recordstructure, wherein the first consumer record structure has first fieldsthat differ from second fields of the second consumer record structure.In an embodiment, the first value is assigned to the particular fieldfor a plurality of master consumer records; the message is a query thatselects for the first value; and the method further comprisesidentifying one or more master consumer records to return based on trustscores assigned to different fields of different source collections fromwhich the plurality of master consumer records were generated. In anembodiment, the first entity is a first retailer and the second entityis a second retailer.

According to an embodiment, a method comprises storing consumer recordscomprising data collected from different sources, wherein each of theconsumer records includes a plurality of values for a plurality ofattributes, including one or more consumer credentials; storing logs ofprevious actions taken by consumers in association with the differentsources, wherein the logs include credentials that map the logs to theconsumer records; receiving a request to provide access to particularcontent, wherein the request includes one or more particular credentialsand metadata associated with the request; determining that a firstconsumer record and a second consumer record share the same one or moreparticular credentials; selecting a particular consumer record, of thefirst consumer record and the second consumer record, based on comparingthe metadata associated with the request to information stored in orderived from the logs of previous actions taken by consumers; andresponding to the request based on consumer access data associated withthe selected particular consumer record.

In an embodiment, the first consumer record and the second consumerrecord include, in addition to the one or more particular credentials,one or more other credentials that are not equivalent, wherein the oneor more other credentials were not included in the request. In anembodiment, the method further comprises matching ambiguous logs torecords based on comparing transaction metadata data of ambiguous log tologs that present unambiguous credentials. In an embodiment, themetadata includes at least one of: location data, basket data, or timeor day of the week. In an embodiment, access is provided to an offer. Inan embodiment, the method further comprises determining that the offerwas previously marked as redeemed in response to a request thatpresented other credentials associated with particular consumer record.Responding to the request comprises declining the request.

8.3. Targeting

According to an embodiment, a method comprises storing event datadescribing a plurality of events that comprise a plurality oftransactions and a plurality of web requests. The method furthercomprises storing target definition data describing a plurality oftarget contexts. The method further comprises storing targeted offerdata describing a plurality of offers. Each particular offer of theplurality of offers associated with one or more particular targetcontexts, of the plurality of target contexts, to which the particularoffer is targeted. The method further comprises, based on the eventdata, correlating particular events of the plurality of events toparticular consumer records. The method further comprises receiving,over a network, a request indicating a first event. The method furthercomprises correlating the first event to at least a first consumerrecord. The method further comprises, based at least on one or moreevents, other than the first event, that have been correlated to thefirst consumer record, identifying a context for the first event. Themethod further comprises, matching the identified context to a firsttarget context of the plurality of target contexts. The method furthercomprises selecting one or more offers, of the plurality of offers, thatare associated with the first target context. The method furthercomprises providing data describing the one or more offers to one ormore devices in response to the request. In various embodiments, one ormore data processing systems and/or one or more logic modules mayperform all or a subset of the foregoing steps.

In an embodiment, the method further comprises presenting informationabout the one or more offers to a device associated with the firstconsumer record. The device may or may not have sent the request. In anembodiment, identifying the context is further based on one or more of:information associated with the first consumer record, such asdemographic data or historical transaction data, or the first eventitself. In an embodiment, the method further comprises automaticallyactivating the one or more offers for use in association with the firstconsumer record. In an embodiment, the events further include aplurality of location events. In an embodiment, the one or more eventsother than the first event include one or more location events. Theidentified context is a trip by a consumer associated with the firstconsumer record to a particular location, such as from home to a grocerystore. In an embodiment, the identified context is the opening of acertain application, such as a retailer-provided application, shoppinglist management application, or coupon application, on a consumer deviceat a particular location. In an embodiment, the target definition datacomprises describes two particular contexts that differ only in the typeof device, such as a mobile device as opposed to a desktop device, fromwhich one or more events associated with the two particular contexts arereceived.

In an embodiment, the identified context is the purchase of a particularitem by a consumer within a particular period of time. The one or moreevents, other than the first event, include a transaction event from afirst retailer indicating that the particular item was purchased by aconsumer linked to the first consumer record. The request is from asecond retailer. The method further comprises sending information aboutthe one or more selected offers to the second retailer, in response tothe request.

In an embodiment, the request is for a receipt for a particulartransaction, and the first event is the particular transaction. In anembodiment, at least a subset of the plurality of events are detected inlogs stored on a server. In an embodiment, at least a subset of theplurality of events are generated in response to messages from aplurality of different endpoints, including one or more of a retailerterminal, retailer website, consumer device, social networking server,or payment server. In an embodiment, the event data is aggregated in adata store. In an embodiment, correlating the first event to the firstconsumer record comprises determining probabilities that the first eventreflects activity by each of a plurality of consumers, and selecting thefirst consumer record because the first consumer record describes afirst consumer that is associated with a highest probability of theprobabilities. In an embodiment, the method further comprisesautomatically defining new target contexts based on historical eventdata.

According to an embodiment, a method comprises receiving, via an offercreation interface at an offer distribution server computer, offerdefinition data describing a plurality of offers, each offer of theplurality of offers comprising a plurality of offer terms. The methodfurther comprises storing target definition data describing a pluralityof contexts under which requests to the offer distribution server mayoccur. The method further comprises receiving, via the offer creationinterface, target association data that associates each particulartargeted offer, of a plurality of targeted offers in the plurality ofoffers, with particular target definition data in the target definitiondata. The particular target definition data describes one or moreparticular contexts to which the particular targeted offer is targeted.The particular target definition data is separate from the plurality ofoffer terms. The method further comprises receiving, at the offerdefinition server computer, from a requestor, a request associated witha request context. The method further comprises matching the requestcontext to a particular context described in the target definition data.The method further comprises based on the target association data,selecting, for inclusion in a response to the request, a targeted set ofone or more offers, from the plurality of targeted offers, that thetarget association data associates with the particular context. Themethod further comprises, without taking into account the targetassociation data, selecting, for inclusion in the response to therequest, a recommended set of one or more offers, from the plurality ofoffers, that are ranked highly with respect to the request context. Themethod further comprises sending the response to the requestor,including information about both the targeted set of one or more offersand the recommended set of one or more offers.

In an embodiment, a recommendation engine performs the selection of arecommended set of offers. In an embodiment, the target association dataincludes bid amounts to compensate an offer distributor for selectingparticular targeted offers for particular contexts. In an embodiment, anoffer distributor is compensated differently for selecting offers in thetargeted set of offers than for selecting offers in the recommended setof offers. In an embodiment, the method further comprises presentinginformation about the targeted set of offers in a separate section ofthe response than information about the recommended set of offers. In anembodiment, the method further comprises merging information about thetargeted set of offers and information about the recommended set ofoffers in a single list within the response. In an embodiment, themethod further comprises automatically activating an offer for use by aconsumer associated with the request based on the offer being in thetargeted set of one or more offers, wherein offers in the recommendedset of one or more offers are not automatically activated.

In an embodiment, the method further comprises determining the requestcontext based on external data, including one or more events and/orinformation associated with a particular consumer record that isassociated with the request. In an embodiment, the particular consumerrecord does not necessarily describe the requestor, but rather therequestor may be a retailer or web service provider. In an embodiment,selecting the targeted set of offers comprises ranking offers associatedwith the particular context by a universal scoring mechanism andfiltering low-scoring offers to identify the targeted set of offers. Inan embodiment, the request context includes a certain combination of oneor more events that occur in a timespan. Matching the request contest tothe particular context involves finding which one or more contextsinclude the certain combination of one or more events. By contrast,selecting the recommended set of one or more offers involves generatingsignals based on the certain combination of one or more events andinputting the signals into one or more scoring functions. In anembodiment, the request context is specified by requestor.

8.4. Recommendations

According to an embodiment, a method comprises storing offer datadescribing a plurality of offers. The method further comprisesidentifying a plurality of collections of itemsets. The collectionsinclude at least a first collection of itemsets derived from transactionlogs and a second collection of itemsets derived from logs in one ormore of: offer activation logs, offer redemption logs, or offerimpression logs. Each itemset in the first collection comprises itemsindicated by the transaction logs as having been purchased together.Each itemset in the second collection comprising items that appeartogether within a same log of the logs. The method further comprises,for each different collection, generating associations between pairs ofitems that co-occur within the itemsets. The method further comprises,for each different collection, calculating association scores for one ormore of the associations. The association scores reflect an actual orestimated frequency of co-occurrence of the items corresponding to theassociation within itemsets belonging to the collection. The methodfurther comprises receiving a request for offer recommendations. Therequest is associated with one or more items. The method furthercomprises for each different collection, matching the one or more itemsassociated with the request to particular associations within thecollection. The method further comprises, for each different collection,identifying a set of related items based on the matched particularassociations. The method further comprises merging the sets of relateditems. The method further comprises ranking the items in the merged setbased at least in part on the association scores. The method furthercomprises selecting a set of offers to recommend based on the rankeditems in the merged set.

In an embodiment, selecting the set of offers comprises selecting offersassociated with any items in the set of related items. In an embodiment,the items in at least one itemset include products and offers, whereinselecting the set of offers comprises selecting offers associated withany products in the set of related items. In an embodiment, the methodfurther comprises identifying the plurality of collections based atleast on a context associated with the request. In an embodiment, theplurality of collections are part of a superset of collectionscomprising different collections of the same type for different users orgroups of users. In an embodiment, only collections of itemsetscollected for web-based events are utilized when the request isassociated with a web-based event. In an embodiment, items includeevents. At least some of the associations are between offers and certainuser actions described in a behavioral log.

In an embodiment, the scores from each different function are assigneddifferent weights. In an embodiment the weights vary depending on acontext associated with the request. In an embodiment, the merged setincludes one or more items found in different sets of related items fromdifferent collections. The ranking function is a function of theassociation scores from each collection in the plurality of collections.In an embodiment, association scores are estimated scores computed fromone or more scoring functions that were learned from one or moretraining subsets of itemsets from the one or more collections. In anembodiment, association scores are based actual frequencies ofco-occurrence within the itemsets of each collection. In an embodiment,different scoring functions are applied to a single collection,depending on the context of the request. In an embodiment, differentscoring functions may be optimized for different objective functions,including one or more of revenue per impression, revenue per activation,or revenue per redemption. Objective functions may be optimized relativeto different requestors or consumers associated with a request,including different objective functions for different consumers, groupsof consumers, providers, or retailers.

In an embodiment, the itemset collections include collections for eachof: shopping lists, web clickstreams, offers clickstream, offeractivation logs, offer redemption logs, and transaction logs. In anembodiment, association scores are further based on other signalsderived from event data or other information associated with therequest, such as location events or demographic data. In an embodiment,selecting the set of offers comprises multiplying association scores forparticular items by universal scores for particular offers pertaining tothe particular items.

According to an embodiment, a method similar to that described aboveinvolves only a collection of itemsets describing offers that areredeemed together in transactions, or offers that are redeemed by a sameconsumer. Hence, association scores would describe offers that arefrequently redeemed together, or are likely to redeemed together.Recommendations are generated based thereon.

According to an embodiment, a method comprises storing offer datadescribing a plurality of offers. The method further comprisesidentifying a collection of itemsets, each itemset of the itemsets beinga set of items that appear together in a particular context. The methodfurther comprises receiving a request for offer recommendations. Therequest is associated with one or more items. The method furthercomprises generating associations between pairs of items that co-occurwithin the itemsets. The method further comprises calculatingassociation scores for one or more of the associations. The associationscores reflect an actual or estimated frequency of co-occurrence of theitems corresponding to the association within itemsets belonging to thecollection. The method further comprises matching the one or more itemsassociated with the request to particular associations within thecollection. The method further comprises identifying a set of relateditems based on the matched particular associations. The method furthercomprises identifying offers associated with items in the set of relateditems. The method further comprises calculating universal scores for theidentified offers, the universal score for each offer being based atleast in part on a measure of revenue associated with activation orrecommendation of the offer. The method further comprises ranking theidentified offers based at least in part on the universal scores and theassociation scores. The method further comprises selecting a set ofoffers to recommend based on the ranked offers. In an embodiment,wherein the measure of revenue is relative to one or more of: an offerdistributor or a retailer associated with the request. Techniques forcalculating universal scores are described subsequently.

According to an embodiment, a method comprises identifying a set ofoffers responsive to a request. The method further comprises calculatinguniversal scores for the set of offers. The calculating comprising, foreach offer in the set of offers, calculating a function of: a firstratio of total activations for the offer to average total activationsfor all offers in a plurality of offers, a second ratio of totalimpressions for the offer to average total impressions for all offers inthe plurality of offers, and a third ratio of total redemptions for theoffer to average total redemptions for all offers in the plurality ofoffers. The method further comprises ranking the set of offers based atleast in part on the universal scores. The method further comprisesproviding information about at least a subset of the ranked set ofoffers in response to the request.

In an embodiment, calculating a universal score comprises comparinghistorical performance of the offer to average offer performance formultiple offers in a group of offers. In an embodiment, calculating theuniversal score for comprises calculating a function of at leastactivations, redemptions, and impressions for the offer. In anembodiment, calculating the universal score comprises calculating afunction of at least offer inventory and offer end date. In anembodiment, calculating the universal scores comprises calculatingpredetermined universal scores based on a set of signals in advance ofreceiving the request. In an embodiment, calculating the universalscores comprises calculating delta changes to the predetermineduniversal scores based on changes in the signals between the time thatthe predetermined universal scores were originally calculated and thetime that the request was received. In an embodiment, calculating theuniversal score for a particular item is based on a manually specifiedsponsorship score for the particular item.

In an embodiment, the first ratio, second ratio, and third ratio areweighted. In an embodiment, different weights are learned for differentcontexts. In an embodiment, the first ratio, second ratio, and thirdratio are weighted based on data that is specific to certain groups ofusers. In an embodiment, the plurality of offers is the identified setresponsive to the request. In an embodiment, the plurality of offers isa set of all available offers, including offers not in the setresponsive to the request. In an embodiment, a universal score isdetermined for a new offer, or an offer for which there is not yet athreshold amount of data, as a ratio average totals from a group ofoffers to average totals of the plurality of offers. The group of offersis a subset of the plurality of offers, of which the new offer is part.

8.5. Offer Creation

According to an embodiment, a method comprises storing transaction datafor a plurality of customers from a plurality of different sources. Themethod further comprises correlating transaction data for particularcustomers to form transaction histories specific to each of theparticular customers. The method further comprises identifying, in thetransaction histories, trends with respect to a set of products in thetransaction histories. The method further comprises based on the trends,generating offer data describing one or more potential offers withrespect to the set of products. The method further comprises presenting,to an advertiser, an interface displaying information about the one ormore potential offers. The method further comprises receiving aselection from the advertiser of a particular offer in the one or morepotential offers. The method further comprises adding particular offerdata describing the selected particular offer to a repository of offerdata. The method further comprises based on the repository of offerdata, responding to requests from customers to access the particularoffer.

In an embodiment, generating the offer data describing the one or morepotential offers occurs interactively as user defines one or moreinitial parameters. In an embodiment, generating the offer data occursin response to user input identifying one or more products, orcategories of products, for an offer, or in response to a specificationof a start date and an end date for an offer. In an embodiment,generating the offer data occurs periodically. In an embodiment,presenting the interface displaying the information about the one ormore potential offers comprises sending the advertiser a weekly email.In an embodiment, presenting the interface displaying the informationabout the one or more potential offers comprises presenting theinformation when the provider first accesses an offer creation interfaceat the beginnings of particular time periods. In an embodiment, themethod further comprises ranking the one or more potential offers by apredicted measure of revenue to the advertiser. In an embodiment, themethod further comprises ranking the one or more potential offers by apredicted increase in sales volume. In an embodiment, generating theoffer data is based partly on a history of what offers the advertiserhas created before.

In an embodiment, presenting the interface displaying the informationabout the one or more potential offers comprises showing an estimatedkey performance indicator for each proposed offer. In an embodiment, themethod further comprises receiving, via the interface, input thatmodifies a potential offer. In an embodiment, the method furthercomprises presenting a recalculated key performance indicator based onone or more changes made by the advertiser to a potential offer. In anembodiment, the method further comprises identifying price points for apotential offer based on information about prices at which an item waspreviously purchased. In an embodiment, the method further comprisesidentifying one or more proposed terms of a potential offer based onfrequency-of-purchase transaction data. In an embodiment, the one ormore proposed terms include at least one of an offer start and an offerexpiration date. In an embodiment, the method further comprisesidentifying one or more proposed terms of a potential offer based onvolume-of-purchase data. In an embodiment, the one or more proposedterms include at least an offer distribution limit.

In an embodiment, the method further comprises optimizing offer terms toyield a highest estimated profit for retailer. In an embodiment, theestimated profit is determined based on one or more of: redemptionpatterns for previous similar offers, or correlations between purchasehistories for items and redemption patterns for previous similar offersrelated to those items. In an embodiment, the method further comprisesidentifying a proposed targeting context in which to distribute apotential offer based on one or more of offer redemption histories anditem purchase histories. In an embodiment, the method further comprisesidentifying a proposed bid amount to compensate an offer distributor fordistributing the potential offer within the targeting context. In anembodiment, the method further comprises receiving input that modifiesthe proposed bid and presenting one or more estimated metrics showing anestimated effect of the modified proposed bid. In an embodiment, themethod further comprises proposing an offer whose terms require multipletransactions for redemption, in that they can only be redeemed afterdetecting two or more different transactions collectively meetingcertain criteria.

In an embodiment, a method comprises storing, in a repository of offerdata, a dynamic offer record describing a dynamic offer. The dynamicoffer record includes one or more attributes corresponding to terms ofthe dynamic offer. The attributes include at least one variableattribute associated with a value selection scheme. The method furthercomprises identifying a particular customer record in association withwhich the dynamic offer is to be distributed. The method furthercomprises based on the dynamic offer record and transaction dataassociated with the particular customer record, generating custom offerdata describing a custom offer. The generating includes selecting aparticular value for the variable attribute based on applying thetransaction data associated with the particular customer record to thevalue selection scheme. The method further comprises storing activationdata that associates the custom offer data with the particular customerrecord. The method further comprises providing information about thecustom offer, including the at least one dynamically selected term, inresponse to a request associated with the particular customer record.The method further comprises sending information about the customeroffer, including the at least one dynamically selected term, to aretailer for redemption in a transaction associated with the particularcustomer record.

In an embodiment, the method further comprises, based on the valueselection scheme, varying one or more of: a promotional image shown withdynamic offer; a discount amount of the dynamic offer, products tied tothe dynamic offer, an expiration date of the dynamic offer, or a startdate of the dynamic offer. In an embodiment, the value selection schemeis based on one or more metrics that indicate an estimated value to aprovider for providing the dynamic offer to a particular consumer. Theone or more metrics are based on previous transaction data and/orprevious offer redemption data associated with the particular consumer.In an embodiment, the method further comprises sending informationindicating terms of the customer offer to a clearinghouse.

What is claimed is:
 1. A data processing system for assisting an offerdistributor to manage electronic offers, the system comprising: a firstlogic module adapted to receive at least two electronic offers fromdifferent offer providers, a first set of offer data relating to thefirst offer, and a second set of offer data relating to the secondoffer; and a second logic module adapted to select one of the two offersfor distribution to a consumer, the selection being based on the firstset of offer data and the second set of offer data.
 2. The dataprocessing system of claim 1, wherein the selected offer is distributedin response to a request for a receipt.
 3. The data processing system ofclaim 2, wherein the selected offer is included in a transaction receipttransmitted to a customer data processing system.
 4. The data processingsystem of claim 3, wherein the customer data processing system is atleast one of: a desktop computer, laptop computer, netbook, electronicnotebook, ultra mobile personal computer (UMPC), electronic tablet,client computing device, client terminal, client console, mobiletelephone, smartphone, wearable computer, head-mounted computer, orpersonal digital assistant.
 5. The data processing system of claim 1,wherein the selection of the offer is further based on an incentiveprovided by one of the offer providers to the offer distributor.
 6. Thedata processing system of claim 1, wherein one of the offer providers isan offer distributor, and the selection of the offer is further based onan incentive provided by the offer distributor.
 7. The data processingsystem of claim 1, wherein at least one of the first set of offer dataand the second set of offer data includes one or more of: an offerprovider identity, a historical or projected impact of an offer on salesof an item, a historical or projected offer redemption rate, ahistorical or projected profit per offer impression, a historical orprojected profit margin, a historical or projected offer volume, ahistorical or projected offer yield, a historical trend in offers madeavailable by an offer provider, a historical or projected profit marginfor the offer distributor, a historical or projected profit margin foran offer provider, a historical or projected impact of an offer on otheroffers, or a historical or projected impact of an offer on consumerbehavior.
 8. The data processing system of claim 1, wherein theselection is made in response to a set of events, or is further based ona set of events.
 9. The data processing system of claim 7, wherein theset of events includes at least one of: an electronic transaction, a webrequest, an offer redemption, an offer activation, a visit by a consumerto a specific location, use of a smartphone application, use of anelectronic shopping list, an ATM withdrawal, reserving, booking orembarking on an airline flight, the filling or issuance of a medicalprescription, a visit to a manufacturer's website, adding an item to anonline shopping cart, viewing or activating an offer on the offerdistributor's website, viewing a digital receipt, an electronic messageto a manufacturer, or an electronic message that references a productfrom a manufacturer.
 10. The data processing system of claim 7, whereinthe set of events is obtained at least in part from a web log, anelectronic transaction log, or a collection of normalized eventscorresponding to a plurality of transactions and web requests.
 11. Thedata processing system of claim 7, wherein at least two events aregenerated in response to messages from different endpoints, includingone or more of a retailer terminal, retailer website, consumer device,social networking server, or payment server.
 12. The data processingsystem of claim 7, wherein at least a subset of the events is aggregatedin a data store.
 13. The data processing system of claim 7, wherein anevent is correlated to a historical transaction record associated with aconsumer based on determination of a probability that the event reflectsactivity by that consumer.
 14. The data processing system of claim 1,wherein the selection is further based on a set of target contexts. 15.The data processing system of claim 13, wherein the set of targetcontexts includes at least one: demographic information about a consumeron whose behalf a request was likely made, a location associated with arequest, information about a retailer associated with a request,transactional or offer-related actions taken by a consumer, one or moreitems in an electronic shopping list or shopping cart associated with aconsumer, or a time or day when a request was made.
 16. The dataprocessing system of claim 13, wherein at least one target context isautomatically defined based on a set of historical transaction records.17. The data processing system of claim 1, wherein the selection isfurther based on a set of historical transaction records.
 18. The dataprocessing system of claim 16, wherein the set of historical transactionrecords include at least one of: a universal product code, a quantity ofproduct purchased, a number of items purchased, a transaction amount, atleast a portion of a credit card number used, a payment identifier used,a secure payment hash key, a data processing system or facility, time,date, one or more offers activated or redeemed, a customer name, a phonenumber, a pin number, a password, a code, a loyalty card number, RFIDdata, a device identifier, one or more items that were purchased in aprevious, concurrent or subsequent transaction, or a transaction number.19. The data processing system of claim 1, wherein the selection isfurther based on a set of contextual transaction data.
 20. The dataprocessing system of claim 18, wherein the contextual transaction dataincludes at least one of: information regarding a universal productcode, a quantity of product purchased, a number of items purchased, atransaction amount, at least a portion of a credit card number used, apayment identifier used, a secure payment hash key, a data processingsystem or facility, time, date, one or more offers activated orredeemed, customer name, phone number, pin number, password, code,loyalty card number, RFID data, a device identifier, one or more itemsthat were purchased in a previous or concurrent transaction, or atransaction number.
 21. A method for assisting an offer distributor tomanage electronic offers, the method comprising: receiving at least twoelectronic offers from different offer providers, a first set of offerdata relating to the first offer, and a second set of offer datarelating to the second offer; select one of the two offers fordistribution to a consumer, the selection being based on the first setof offer data and the second set of offer data; wherein the method isperformed by one or more computing devices.
 22. The method of claim 21,further comprising including the selected offer in a transaction receipttransmitted to a customer data processing system.
 23. The method ofclaim 21, wherein the selection is made in response to a set of events,or is further based on a set of events; wherein the set of eventsincludes at least one of: an electronic transaction, a web request, anoffer redemption, an offer activation, a visit by a consumer to aspecific location, use of a smartphone application, use of an electronicshopping list, an ATM withdrawal, reserving, booking or embarking on anairline flight, the filling or issuance of a medical prescription, avisit to a manufacturer's website, adding an item to an online shoppingcart, viewing or activating an offer on the offer distributor's website,viewing a digital receipt, an electronic message to a manufacturer, oran electronic message that references a product from a manufacturer. 24.The method of claim 21, wherein the selection is made in response to aset of events, or is further based on a set of events; wherein the setof events is obtained at least in part from a web log, an electronictransaction log, or a collection of normalized events corresponding to aplurality of transactions and web requests.
 25. The method of claim 21,wherein the selection is made in response to a set of events, or isfurther based on a set of events; wherein at least two events aregenerated in response to messages from different endpoints, includingone or more of a retailer terminal, retailer website, consumer device,social networking server, or payment server.
 26. The method of claim 21,wherein the selection is made in response to a set of events, or isfurther based on a set of events; further comprising correlating anevent to a historical transaction record associated with a consumerbased on determination of a probability that the event reflects activityby that consumer.
 27. The method of claim 21, wherein the selection isfurther based on a set of target contexts; wherein the set of targetcontexts includes at least one: demographic information about a consumeron whose behalf a request was likely made, a location associated with arequest, information about a retailer associated with a request,transactional or offer-related actions taken by a consumer, one or moreitems in an electronic shopping list or shopping cart associated with aconsumer, or a time or day when a request was made.
 28. The method ofclaim 21, wherein the selection is further based on a set of historicaltransaction records. wherein the set of historical transaction recordsinclude at least one of: a universal product code, a quantity of productpurchased, a number of items purchased, a transaction amount, at least aportion of a credit card number used, a payment identifier used, asecure payment hash key, a data processing system or facility, time,date, one or more offers activated or redeemed, a customer name, a phonenumber, a pin number, a password, a code, a loyalty card number, RFIDdata, a device identifier, one or more items that were purchased in aprevious, concurrent or subsequent transaction, or a transaction number.29. The method of claim 21, wherein the selection is further based on aset of contextual transaction data. wherein the contextual transactiondata includes at least one of: information regarding a universal productcode, a quantity of product purchased, a number of items purchased, atransaction amount, at least a portion of a credit card number used, apayment identifier used, a secure payment hash key, a data processingsystem or facility, time, date, one or more offers activated orredeemed, customer name, phone number, pin number, password, code,loyalty card number, RFID data, a device identifier, one or more itemsthat were purchased in a previous or concurrent transaction, or atransaction number.
 30. One or more computer readable media storingprogram instructions adapted to manage electronic offers, whereinexecution of the program instructions by a data processing systemcauses: receiving at least two electronic offers from different offerproviders, a first set of offer data relating to the first offer, and asecond set of offer data relating to the second offer; select one of thetwo offers for distribution to a consumer, the selection being based onthe first set of offer data and the second set of offer data;